Capstone: Would You Use Microservices Here?

1. How to Use This Capstone

This capstone gives you three scenarios. Each one is a realistic version of the same decision: would you use microservices here?

For each scenario, do three things. Read the setup. Say your answer out loud before you read further. Then compare it against the worked answer and the notes on what a complete answer covers.

The out-loud step is the whole point. Recognition and recall are different skills. Reading a good answer and agreeing with it feels like learning, but the real test is producing the answer yourself with nothing in front of you.

A strong answer to any decision like this has the same four parts:

1. Restate the constraint that decides it. Team size, domain stability, load shape, or ops maturity. Load shape is how traffic and resource needs spread across the system. Ops maturity is how ready the team is to run many services in production.
2. Give the decision. Commit to one. Staying between two options without choosing is worse than either choice.
3. Name what you are giving up. Every architecture costs something, so say what it costs.
4. Name the trigger that would change your mind. This turns a static opinion into engineering judgment.

2. Scenario A: The Startup

"We are a 10-day-old startup, 8 engineers, building a B2B invoicing product. Our CTO wants to start with microservices so we don't have to rewrite later. You are the founding architect: what do you recommend?"

One term before you answer. B2B means business to business. The customers are other companies, not consumers.

Say your answer, then read on.

A strong answer: "I would recommend a modular monolith, and I would disagree with the rewrite argument directly. With 8 engineers we have one team, so the coordination problem microservices solve does not exist here yet. What we would pay for them is real, though: every feature would cross network boundaries, we would need distributed tracing and per-service pipelines before we have a single customer, and our domain boundaries are guesses right now because the product will change as we learn. Wrong boundaries are the expensive part, and they are far cheaper to fix inside one codebase. So we ship one deployable and one database, but we enforce module boundaries from the start: separate modules for invoicing, customers, and payments, each owning its own tables, with no cross-module table access. That discipline is what makes a later extraction cheap, which answers the CTO's concern better than starting with microservices does. The trigger to revisit: when we have several teams genuinely blocking each other's releases, or a component like PDF rendering whose load diverges enough to need its own scaling."

Two terms from that answer are worth defining. Distributed tracing means following a single request as it hops between services, so you can see where it slowed down or failed. Per-service pipelines means every service needs its own build, test, and deploy automation.

What a complete answer covers. Three things.

1. The modular monolith, not just "monolith." A modular monolith is one deployable app with strict module boundaries inside it. Each module works like a library with a public interface: other modules call the interface and never reach into its tables.
2. An explicit reason the CTO's "avoid the rewrite" logic fails: boundaries are guesses right now, and clean modules make a later extraction cheap.
3. A concrete revisit trigger.

One more thing worth adding: a specific piece like PDF rendering can be extracted on its own someday without adopting microservices everywhere.

3. Scenario B: The Release Train

"You join an e-commerce company: 300 engineers, around 40 teams, one Java monolith. Releases go out twice a month on a train; a bug in any team's code rolls back everyone. Teams openly plan around missing the train. Would you move to microservices?"

Say your answer, then read on.

A strong answer: "Yes, this is the situation microservices exist for: the constraint that decides it is 40 teams measurably blocked by one deployment unit. The coordination cost is visible and growing, and it is organizational, so the fix has to change the organization's units of deployment. But I would not split everything at once. I would start with the strangler approach: pick one or two boundaries where the case is strongest, meaning a domain a single team owns, with its own data and a load or release profile that diverges from the rest. Checkout and search are typical first choices. Each extraction gets its own database from the start, because sharing tables with the monolith would keep the coupling and add a network in the middle. What we are giving up: cross-boundary transactions and easy debugging, so the platform work (tracing, centralized logging, deployment automation) has to be built alongside the first services, not after them. Success metric: deployment frequency per team and rollback blast radius, measured before and after. And the end state does not have to be 300 services; it has to be release independence. If we get there with 15 services around a smaller core monolith, that is success."

What a complete answer covers. Four things. A yes, with the reason tied to team count and release contention rather than scale or traffic. An incremental migration rather than one giant rewrite that splits everything at once. Data ownership from the first extraction. And the point that the end state is measured in release independence rather than service count.

Two more terms worth being able to define. The strangler approach means extracting services one at a time while the monolith keeps running and shrinks over time. The name comes from the strangler fig, a plant that grows around a tree and slowly replaces it. Blast radius means how much of the system one failure or one rollback takes down with it.

4. Scenario C: The Hot Component

"A 25-engineer company runs a profitable photo-book product as a Rails monolith. Everything is fine except image processing: it consumes 80% of compute, needs GPU instances the rest of the app wastes money on, and a traffic spike in uploads slows down checkout. Microservices?"

Say your answer, then read on.

A strong answer: "Not microservices, one microservice. The constraint that decides it is load shape: one component whose resource profile (GPU, spiky, compute-heavy) diverges completely from the rest of a system that is otherwise healthy. Extracting image processing into its own service, with a queue in front of it, solves all three named problems at once: it scales independently on GPU instances, the rest of the app goes back to cheap CPU instances, and the queue means an upload spike makes processing slower instead of affecting checkout at all. Image processing is also a naturally clean boundary: the interface is 'here is an image and a job spec, tell me when you are done,' jobs are self-contained, and it needs no cross-service transactions. What we pay: an async workflow, so the product now needs job status handling and retry logic for failed processing, and the team takes on operating a queue. That cost is small and local. The rest of the monolith stays exactly as it is, and the trigger for any further extraction would be the same kind of evidence: a specific component with a divergent profile, not a general desire to modernize."

What a complete answer covers. It refuses the false binary. A false binary is a choice framed as two options when a third exists. Here the third option is one targeted extraction, not an architecture migration.

It also names the queue as the decoupling mechanism, and observes that this particular boundary is clean, with self-contained jobs and no distributed transactions. The best answers name the new costs, meaning async status handling and retries, without being asked.

5. The Pattern Across All Three

Notice what decided each scenario. Team structure decided A and B. Load shape decided C. Never traffic volume by itself, never company prestige, never "modern versus legacy."

The details change every time. The deciding variables rarely do, and that is what makes this decision learnable instead of something you memorize case by case.

💡 If you can only rehearse one sentence from this module, rehearse a version of: "My default is a modular monolith; I split when the evidence shows teams blocking each other or a component whose needs diverge, and each split has to be worth its own operational cost."

Next comes the question that follows every "yes, split" decision: where exactly do you draw the lines? That is the next module's subject, and it is where most real-world microservice systems go wrong first.

6. TL;DR