How many engineers do you need before microservices make sense?

There is no magic number, but the common experience is that the coordination pain of a shared codebase starts beating the operational pain of distribution somewhere past 50 engineers. Below that, a modular monolith with enforced boundaries usually ships faster. A specific forcing function, like one component with 10x different scaling needs or separate compliance requirements, can justify an earlier split for that component alone.

Can microservices share a database if they own different tables?

Sharing a database server is a pragmatic cost choice some teams make; sharing tables is where independence dies. If two services read and write the same tables, a schema change requires coordinating both, and you have a distributed monolith. The workable compromise is separate schemas or databases per service on shared infrastructure, with all cross-service access going through APIs or events.

What happens to transactions when data is split across services?

You lose ACID across the boundary and adopt the saga pattern: a sequence of local transactions where each step has a compensating action that undoes it if a later step fails. An order saga might reserve inventory, charge the card, then confirm; if the charge fails, a compensating step releases the reservation. It works, but it is real complexity, which is a strong argument for keeping data that must change together inside one service.

Architecturechapter 1 of 5 · 4 lessons

Monolith vs Microservices

One deployable unit vs many small independent services, each with real trade-offs.

← All chapters View in cheatsheet

Forty engineers push to one repository. The deploy queue is nine changes deep, and a flaky test in the analytics code has been blocking everybody's release since Tuesday.

Somebody says the word microservices and half the room nods.

Notice what actually hurts there. Nobody said the site is slow, or that they cannot handle the traffic. They said they cannot ship. That is a problem about people, not about machines, which is why this argument produces more bad decisions than anything else here: it gets treated as a technology choice when it is an organisational one.

The honest question is not which architecture is better. It is what is hurting right now, and which shape makes that specific pain cheaper.

Lessons

4 in this chapter

What a Monolith Really IsOne codebase, one build, one deploy. That is the whole definition, and it is not a slur.2 min
What Microservices Buy and What They CostIndependent deploys and independent scaling, paid for with the full distributed systems tax.2 min
The Distributed Monolith TrapNetwork hops of microservices, coupling of a monolith. The worst square on the board.2 min
How to Actually MigrateStrangle the monolith one seam at a time. Big-bang rewrites die in year two.3 min