The picture to keep in your head

Every question below is answered twice: first in the restaurant, so you can picture it, then in the system, so you know exactly how it works. Each answer ends with a memory code to lock it in.

The picture to keep in your head

A family restaurant has one kitchen. One menu, one head chef, one set of pots. When the tandoor cook needs paneer, they reach across and take it from the curry station. Fast, simple, and everybody knows everybody. As the restaurant grows, the kitchen gets crowded: cooks bump into each other, and changing one dish means checking with everyone.

A food court works differently. Each stall has its own counter, its own staff, its own pantry and its own opening hours. The dosa stall can change its menu tomorrow without asking the biryani stall. But now there's a directory board so customers can find stalls, a shared seating area to manage, and if your thali needs something from three stalls, you queue three times.

Between the two is a big restaurant with clear stations: one kitchen, but the tandoor, curry and dessert stations each have their own space and their own shelf, and nobody grabs from another station's shelf without asking.

That's this chapter: a monolith, a modular monolith and microservices, and how to choose.

Our running example: the bookstore's backend: catalogue, cart, orders, payments, search and recommendations. It started with 5 engineers and is growing to 60. Latencies and availability figures are assumptions for practice.

Figure: a food court lets stalls move fast alone, but someone now has to run the whole court.

---