Monolith to Microservices: When and Why

The three-tier architecture from the start of this course, one codebase, one deployable unit and one database, is a monolith, and it is the right starting point for almost every system. Nothing in this course so far has needed more than that. Microservices, the alternative where an application is many small services that deploy and scale on their own, are fashionable, so it is tempting to start there. This chapter explains when the split earns its cost, and when it does not.

A small restaurant has one cook who does everything, and for 20 covers a night that is the best arrangement: nothing to coordinate, nothing lost in hand-offs. At 500 covers it breaks down, so the kitchen splits into stations: grill, salad, pastry, each with its own tools and its own head. Each station can work at its own pace and be staffed to its own demand. But now orders have to be passed between stations, a late salad delays the whole table, and somebody has to coordinate the pass.

• -The single cook is the monolith: simple, nothing to coordinate, and hard to grow past a point.
• -The stations are microservices: independent, each scaled and run by its own team.
• -The tickets passed between stations are network calls, which can be slow and can fail.
• -The coordination at the pass is the new operational work that splitting creates.

• -Team scaling: many teams committing to one codebase step on each other's changes and deploy schedules. This is the strongest signal, and it is about people more than technology.
• -Uneven scaling: one feature, say image processing, needs 100 times the compute of everything else, but you are forced to scale the whole monolith together.
• -Independent release cadence: one team wants to ship five times a day while another needs a slow, careful release, and a monolith forces them onto one schedule.
• -Technology fit: a specific workload is genuinely better served by a different language or runtime.

Notice what is not on the list: a monolith being big, or old, or unfashionable. A team of six that ships weekly and has nothing scaling unevenly has no reason to split.

None of this is free. Function calls become network calls. Say one user request now passes through 5 services in a chain, and each is 99.9% available, which sounds excellent. As the availability chapter showed, chained availabilities multiply: 0.999 to the power of 5 is about 99.5%, which is roughly 44 hours of downtime a year instead of the 8.8 hours of a single 99.9% service. Latency adds up too: five sequential calls at 5 ms of network time each add 25 ms before any real work is done.

• -Reliability and latency: every hop is a new place to fail or be slow, which is why the previous module's circuit breakers, retries and timeouts become essential.
• -Data: a transaction that used to be one database COMMIT now needs a saga, also from the previous module.
• -Operations: you have gone from deploying and watching one thing to deploying and watching many, which needs tracing, central logs and automation.

A common trap deserves its own warning.

• -Split by business capability, not by technical layer. Users, Orders and Payments are good services; a service called Database Access is not.
• -Give each service its own database, and let others reach the data only through the service's API. Shared tables are the quickest route to a distributed monolith.
• -Go gradually. A well-known approach, the strangler fig, builds the new service beside the monolith and moves traffic to it piece by piece, until the old code for that feature can be removed.
• -Consider a modular monolith first: one deployable unit, but with strict boundaries between modules. It gives you most of the structure and can be split later along lines that already exist.

The diagram shows the end state: a gateway in front of independently deployable services, each with its own database.