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.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.