Skip to main content
Monolith vs Microserviceslesson 2 of 4 · 2 min read

What Microservices Buy and What They Cost

Independent, not small

Microservices split your system into services that each own their code, their data, and their release schedule.

People fixate on the word small. The word that matters is independent. Your payments team ships on Tuesday without asking the search team. Recommendations scales to 200 machines while billing runs on 4. A memory leak kills one service instead of the site.

Own your data, which is the part newcomers miss. Real microservices do not share tables.

The orders service owns the orders schema, and anyone who wants order data goes through its API or listens to its events. That is what makes the independence real, because shared tables are shared coupling: change a column and you break three teams you have never met.

The bill

Now read the bill. Every function call that became a network call picked up latency, a failure mode, and the cost of encoding and decoding.

Transactions that spanned one database now span services, and there is no atomic commit across a network. You get sagas instead: chains of local transactions with compensating steps for when the fourth one fails after the second one committed.

Debugging becomes tracing across a dozen hops. You need service discovery, dashboards per service, versioned contracts, and somebody on call for each one. A service mesh absorbs some of the plumbing and is itself one more thing to operate.

Apply the rule that survives contact with reality. The split pays off when the cost of many teams coordinating in one codebase exceeds the cost of operating a distributed system.

Expect that crossover somewhere past fifty engineers, or earlier if one component genuinely has different scaling or compliance needs. It almost never happens at ten.

the shape of it
One processfunction callSplit apartNow a network callhalf a millisecondAnd it can failAnd so can step four1. independence2. the cost3. new failure mode4. no atomic commit
step 1 of 4
Every function call that becomes a network call gains latency and a way to fail.

Worked example

Netflix is the canonical payoff story, but the numbers matter more than the logo. Between 2009 and 2016 they went from a DVD-era monolith to roughly 700 services, because thousands of engineers could not ship through one release train and streaming components had wildly different scaling profiles. The counterexample comes from the same company: in 2023 the Prime Video quality-monitoring team at Amazon published that they had rebuilt their microservices pipeline as a monolith, cutting infrastructure cost by about 90 percent, because their step functions and per-call overhead cost more than the architecture returned for that workload. Same industry, opposite verdicts, and both were right. The deciding variable was team scale and workload shape, not fashion.