From Design to Production

Your marketplace can lose an entire region at dinner rush and keep taking orders. You proved it. You also, at this exact moment, have nothing.

Nobody has deployed it. Nobody can see inside it while it runs. Nobody is paying its bill, because there is no bill, because there is nothing running. What you are holding is a very good argument that a system would survive. That is not the same thing as a system.

This is the course where the argument has to become a machine that other people can run, change, watch, secure, and afford. It is a different kind of hard from what came before, and the difference catches out engineers who are genuinely good at design.

In this lesson: why a design and a running system are separated by an entire discipline, the two acts this course moves through, and the one law that connects them.

Scope: every technology named here gets its own lesson later. Nothing below is a tutorial on Kubernetes, pipelines, tracing, or cost. This is the map and the reason for it.

Draw a box on a whiteboard and label it Orders Service. How long did that take, two seconds?

Now put that box into production. It needs a repository and a build. It needs a container image, and somewhere for that image to live. It needs at least two running copies, because one copy is a single point of failure and you already know how that story ends. It needs configuration that differs per environment, and secrets that must never appear in the configuration. It needs a pipeline that can ship a change and a way to take that change back. It needs logs shaped so a machine can search them, metrics that say whether it is healthy, and an alert that wakes a specific human when it is not. It needs a line item on an invoice, and someone who has agreed to own it.

One rectangle. Eleven things. None of them are the feature.

Here is the honest way to think about what you drew: a design is a hypothesis. It is a claim that a particular arrangement of parts will hold up under real load, real failures, and real change. Hypotheses are valuable. They are also, until tested, just claims, and production is the only place the test runs.

The obvious objection is that we test claims all the time, in staging.

Charity Majors, whose whole career is watching systems fail in ways their builders did not predict, is blunt about that: "Trying to mirror your staging environment to production is a fool's errand. You should just give up now." Her reasoning is not cynicism, it is arithmetic. "Distributed systems are incredibly hostile to being cloned, or imitated, or monitored, or staged." And the thing you would need to clone is not really the code. "Every single unique combination of this point in time of your infrastructure, this deploy artifact, this deploy script is unique."

What production has that no copy of it does: real data, real users, real traffic, real scale, real concurrency, real network, real deploys. You can accept no substitute, because there isn't one.

Sit with the consequence, because it is the reason this course exists. If you cannot rehearse the performance, then the system has to be safe to change during the performance. It has to be legible while it runs, so you can see what it is doing. It has to be reversible while it runs, so a wrong move is survivable. It has to fail in pieces rather than all at once, so a mistake costs a slice instead of the company.

Legible, reversible, and failing in pieces are not properties you sprinkle on afterwards. They are decided by the architecture, months earlier, by someone drawing boxes.

The industry already has a name for the thing this lesson is circling, and the name is better than most jargon because the shape of it carries the argument.

Day 0 is design and architecture. Day 1 is install and first deploy. Day 2 is everything after: patches, upgrades, configuration drift, capacity, cost, and incidents. The vocabulary came out of the infrastructure world and spread through the Kubernetes operator community, where people were forced to admit in public that the work after installation is a different job with a different rhythm.

Look at the asymmetry. Day 0 ends, at a review or a deadline. Day 1 ends, at a deploy you can celebrate. Day 2 has no end date. It runs until the system is switched off, which for anything successful is measured in years.

Estimates of how much of a system's lifetime cost lands in that third phase vary so widely that quoting a precise figure would be dishonest. The range across published sources runs from roughly forty to eighty percent, and the methodologies behind those numbers are soft. What nobody credible argues is that the running half is smaller than the building half. Most engineering careers, and almost every engineering curriculum, are organised around the phases that end.

At Google, a service does not simply arrive in production and start being reliable. There is a literal gate, and it has a name.

"The most typical initial step of SRE engagement is the Production Readiness Review (PRR), a process that identifies the reliability needs of a service based on its specific details."

The review checks that a service "meets accepted standards of production setup and operational readiness" before anyone signs up to carry a pager for it. What makes it worth your attention is not the ceremony, it is the checklist. Two of the items published in the SRE book:

• whether "updates to the service impact an unreasonably large percentage of the system at once"
• whether "all user-visible request failures [are] well instrumented and monitored, with suitable alerting configured"

Read those again with an architect's eye. The first is blast radius. The second is observability. Neither reads like an architecture question, and both are answered almost entirely by architecture. How much of your system one deploy can break is decided by how many independently deployable pieces you built. Whether a failure can be seen is decided by whether requests cross boundaries you thought to instrument.

The gate between designed and running is guarded by operational questions with architectural answers. That sentence is the whole course in one line.

So this course runs in two acts, and it is worth knowing which one you are in at any moment.

Act A — architect at scale. Choose the shape: architecture styles, the patterns that hold services together, what they run on, and how data moves through them in bulk.

Act B — operate and evolve. Live with the shape you chose: ship changes without downtime, see inside a running system, keep it safe, and pay for it.

One piece of housekeeping, quickly, because the previous course already drew this line and there is no sense drawing it twice. Distributed Systems & Reliability answered "how do I not fall over when something breaks?". This course answers "how do I run, watch, secure, and pay for this thing, day after day?". Keeping a region alive through an outage belongs there. Rolling out version two without downtime belongs here.

The two acts are not a filing system. They are a cause and its effect, separated by enough time that most people never connect them. Act A is where you make promises. Act B is where they come due, usually to somebody else, usually at three in the morning.

That claim deserves better than my word for it, so here it is as arithmetic you can drive.

Make four architecture calls on the left. Nothing below them is a separate decision, every number is computed from what you chose: blast radius is a hundred divided by how many things you can deploy, the idle floor is your units multiplied by the replicas each one needs to survive losing a machine, and the debugging cost is how many services one checkout has to cross.

Start as a monolith on virtual machines, then switch Shape to microservices and watch three numbers move at once. Blast radius improves eightfold. The idle bill also goes up eightfold, before a single user shows up. And a request that used to be one stack trace now crosses five machines. Then try microservices with one shared database, which is the arrangement most teams actually end up with, and read what it says.

There is no configuration on that panel that wins on every axis. That is not a limitation of the widget. That is the subject.

Martin Fowler has been asked whether a team should adopt microservices more times than anyone should have to endure, and his answer hardened into a title: you must be this tall to use microservices. He lists what tall means, and the list is short.

Rapid provisioning — "you should be able to fire up a new server in a matter of hours." Basic monitoring — "it's essential that a monitoring regime is in place to detect serious problems quickly." Rapid application deployment — "you need to be able to quickly deploy them, both to test environments and to production," through a pipeline that finishes in no more than a couple of hours. Underneath all three, close collaboration between the people who write the code and the people who run it.

Now put that list beside the second half of this course. Rapid provisioning is Compute & Orchestration. Basic monitoring is Observability. Rapid deployment is Deployment & Evolution. The prerequisites for the architecture are, line for line, the syllabus for operating it.

That correspondence is the best argument I can give you for why the second half of this course is not the boring half. A team that splits into services without those three capabilities has not modernised. It has taken on the costs of a distributed system and purchased none of the benefits, which is the most expensive place in this entire field to stand.

Once a system is running, the argument about whether you are doing this well stops being a matter of taste. The DORA research program measures software delivery with five numbers, and they split into two kinds.

Throughput: change lead time, "the amount of time it takes for a change to go from committed to version control to deployed in production," and deployment frequency. Instability: change fail rate, failed deployment recovery time, and deployment rework rate, the share of unplanned deploys you make because something broke.

The finding that matters most is the one people find hardest to believe. "DORA's research has repeatedly demonstrated that speed and stability are not tradeoffs." The teams that ship most often are also the teams that break things least often, because the same machinery, small changes, fast pipelines, real observability, quick rollback, produces both. In the 2025 report, roughly a fifth of respondents cleared the top band: deploying on demand, change failure rates around five percent, recovery inside an hour.

Two honest footnotes. The famous benchmark, Amazon deploying every 11.6 seconds on an average weekday, comes from a talk in 2011, which should tell you how long this has been possible rather than how impressive it is. And the 2025 report found that heavier AI adoption correlated with more delivery instability, even while individual developers got more effective. Generating changes faster than your machinery can safely absorb them is not an improvement. It is a way of discovering exactly how good your Act B is.

Here is the whole thing on one page, in the order you will meet it.

Act A — architect at scale

1. Architecture Styles — monolith, microservices, serverless, event-driven, and a rubric for choosing rather than following fashion. You are in this part now.
2. Microservices Patterns — if you did split, the machinery that keeps the pieces working together: discovery, gateways, meshes, and who is allowed to own which data.
3. Compute & Orchestration — what the code actually runs on. Containers, the twenty percent of Kubernetes worth knowing, autoscaling, and the decision everyone asks about between managing servers and not.
4. Big Data & Streaming — moving data in bulk and in flight, batch against stream, windows, and counting things at a scale where counting stops being easy.

Act B — operate and evolve

5. Deployment & Evolution — replacing a running engine: pipelines, canaries, feature flags, and migrating a database that is being written to right now.
6. Observability — seeing inside it. Logs, metrics, traces, and following one request through twelve services when a customer says it was slow.
7. Security & Cost — the two bills. Keeping hostile traffic out, keeping secrets secret, and finding out which line of your architecture is quietly the expensive one.

Then everything lands in one place. Capstone Pass 4 takes the same marketplace you just made survive its failures and puts it into production for real: split into services, shipped through a pipeline, watched through proper instrumentation, and held to a budget.

Notice the shape. The first four parts are choices. The last three are consequences.

A course like this one has an obvious failure mode, which is that you finish it and go distribute something that did not need distributing.

So let me put the counter-argument at full strength while you are still fresh. A very large number of real, profitable businesses run on one well-maintained server with good backups. For them, most of Act A would be a hobby funded by their employer. Fowler is direct about the specific version of this mistake: "You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile." His evidence is uncomfortable. "Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble."

The reason is a knowledge problem, not a technology one. "Even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning." Boundaries between services are extremely expensive to move once they exist, and you learn where they belong by operating the system, which you cannot do before it exists.

I will give Fowler the last word here, partly because it is good advice and partly because the humility is the point: "anybody's advice on these topics must be seen as tentative, however confidently they argue." Including this course. What you are learning is not a sequence of correct answers. It is what each choice costs, so you can tell when the price is worth paying.

• "Production is the last step." It is the first day of the longest phase. Day 2 has no end date, and a deploy is where a system starts being your problem, not where it stops.
• "A good design is a working system." A design is a hypothesis. It has not been tested against real traffic, real data, and real failures, and those are the only conditions the test runs under.
• "Staging proves it works." Staging catches the errors you already knew how to look for. Nothing you can build is a copy of production, which is why the ability to observe and reverse changes in production is a design requirement rather than a tooling preference.
• "Microservices are the modern way to build systems." They are one shape with a specific entry fee: provisioning, monitoring, and deployment you already have. Without those three, splitting buys every cost of a distributed system and none of its independence.
• "Operations comes after the architecture." Operations is the architecture, observed later. How much one deploy can break, how long a failure takes to find, and what the system costs while idle were all decided at the whiteboard by someone who thought they were only drawing boxes.

• A design is a hypothesis; production is the only place it is tested. The gap between them is not detail, it is a second discipline.
• You cannot clone production, so a system has to be legible and reversible while it runs, and those properties are decided by architecture.
• Day 0 and Day 1 end. Day 2 does not, and it is where most of a system's lifetime cost and nearly all of its drama live.
• The gate into production is guarded by operational questions with architectural answers: blast radius and observability are both set at the whiteboard.
• Speed and stability are not opposites. The machinery that makes deploys frequent is the machinery that makes them safe.
• Fowler's prerequisites for splitting a system are, line for line, this course's second act. You must be this tall, and this is how you get tall.

Act A opens where every architecture argument starts, with the shape everyone claims to have outgrown and most systems should have kept. Next — Client-Server to N-Tier: the layering instinct, and why it still underpins nearly everything you will draw.