Microservices vs. a Monolith: What Spring Boot Actually Deploys

The Food-Court Analogy

Imagine one enormous restaurant kitchen that cooks absolutely everything on a huge menu — burgers, sushi, pizza, dessert, coffee — all from one shared kitchen, one shared staff, one shared set of ovens and fridges. It works, but it has real problems: if the pizza oven breaks, the whole kitchen might have to shut down, even though nobody ordered pizza. If the sushi chef needs a totally different set of tools than the burger cook, they’re still crammed into the same space, fighting over the same refrigerator. And if you want to change how burgers are made, you risk accidentally breaking something in how sushi gets made too, because it’s all one tangled kitchen.

Now imagine a food court instead. The burger stall, the sushi stall, the pizza stall, and the coffee stall are each their own small, independent operation — their own equipment, their own staff, their own fridge. The pizza oven breaking doesn’t touch the sushi stall at all. The burger stall can change its recipe, hire more staff for a busy lunch rush, or even close for renovation, and every other stall keeps running exactly as before. Customers still walk up to one shared area and place orders — they don’t need to know or care that four separate, independent little businesses are actually serving them.

That one giant shared kitchen is a monolith. The food court — several small, independent stalls, each one self-contained — is a microservices architecture. Each stall is a microservice.

Why Teams Actually Split Systems This Way

Splitting one application into several isn’t free — it trades one set of problems for another (the Intermediate and Advanced levels get into exactly what that trade costs). Teams accept that trade for a few concrete reasons:

• 1

  Independent scaling.If the Order Service gets hammered with traffic during a sale but Payment Service doesn’t, you can run ten copies of Order Service and just one copy of Payment Service. In a monolith, scaling means scaling the entire application, even the parts nobody is actually hitting hard right now.

• 2

  Independent deployment. A team can change, test, and deploy the Inventory Service on its own schedule, without coordinating a release with every other team, and without redeploying — or risking breaking — code that has nothing to do with inventory.

• 3

  Failure isolation.If one service crashes or misbehaves, the food-court effect applies: the other services keep running. A bug in a rarely used reporting feature doesn’t have to be able to take down the checkout flow, if the two live in separate services.

• 4

  Team ownership.A larger engineering org can give one team full ownership of the Order Service and another full ownership of the Payment Service, each free to make their own technical decisions inside their own service’s boundary, instead of everyone stepping on each other inside one shared codebase.

Spring Boot’s Role: Making Each Stall Self-Sufficient

The previous topic in this pillar covered @SpringBootApplication and its embedded server — the fact that a Spring Boot application doesn’t need a separately installed server program to run; it packages its own and can simply be started. That detail, which might have seemed like a minor convenience back in that topic, turns out to be exactly what makes Spring Boot such a natural fit for microservices: everymicroservice needs to be independently runnable and deployable, on its own, without depending on some shared, pre-existing server installation — and that’s precisely what a Spring Boot application already is, out of the box.

Put plainly: a microservice, in this pillar, is a Spring Boot application. It has its own @SpringBootApplication class, its own embedded server, its own @RestController endpoints, and its own beans, wired by its own ApplicationContext. The only thing that’s new here is that instead of running exactly one of these, a system now runs several — an Order Service, an Inventory Service, a Payment Service — each one its own separate, independently deployable Spring Boot application, each one its own food-court stall.

Fun Fact

“Microservices” isn’t a Spring-specific idea, and it isn’t even a Java-specific one — it’s an architectural style that shows up across essentially every programming ecosystem. What Spring Boot specifically contributes is making the “independently runnable Java application” part of that style almost trivially easy, since auto-configuration and the embedded server remove most of the setup work each individual service would otherwise need.

Test Yourself

Ready for the part a food-court analogy can’t quite capture — how these independent services actually find and talk to each other over a real network? Continue to the Intermediate level →