Monolith to Microservices: When and Why
You'll learn to
- -Recognize the signals that justify splitting a monolith
The three-tier architecture from Module 2 (one codebase, one deployable unit, one database) is a monolith, and it's the right starting point for almost every system. Nothing in this course so far has needed more than that. This chapter is about recognizing when it stops being enough.
Signals It's Time to Split
- -Team scaling: many teams committing to the same codebase start stepping on each other's changes and deploy schedules.
- -Uneven scaling needs: one feature (say, image processing) needs 100x the compute of everything else, but you're forced to scale the whole monolith together.
- -Independent deploy cadence: one team wants to ship five times a day while another needs a slow, careful release process, and a monolith forces them onto the same schedule.
- -Technology diversity: a specific workload is genuinely better served by a different language or runtime than the rest of the app uses.
The Cost of Splitting
None of this is free. Function calls become network calls, with all the new latency and failure modes covered in the previous module. A transaction that used to be one database COMMIT now needs a SAGA (also previous module). And operationally, you've gone from deploying and monitoring one thing to deploying and monitoring many.
A common trap: splitting a monolith into services that are still tightly coupled (sharing a database, deploying in lockstep) gets you all of the distributed-systems complexity with none of the independence benefits. Teams call this a "distributed monolith," and it's usually worse than the monolith it replaced.
After splitting: an API Gateway in front of independently deployable services, each owning its own database.
"We have three teams now, let's split into microservices to move faster." Any pushback?
"No: more teams means microservices are the right call."
"Team count alone isn't sufficient justification; whether those teams actually have independent scaling, deployment, or technology needs matters far more than whether they're simply organizationally separate while working on tightly related features. Splitting along the wrong boundaries produces a 'distributed monolith': all the network latency and operational overhead of microservices, with none of the independence, because the services still have to deploy together or share a database anyway."