The Professor
Index Course index

Module 12 · Enterprise level (capstone)

Lesson 53 — Modular monolith vs microservices

A reasoned decision, not a fashion: when to split and when not to.

Published
In this lesson
  1. Exercise 1 — The honest matrix
  2. Exercise 2 — The modularization
  3. Exercise 3 — The contracts between modules
  4. Exercise 4 — The threshold and the strangle
  5. Exercise 5 — Defending the decision
  6. Submit

The monolith's boundaries, today. No solutions.md before submitting.

Exercise 1 — The honest matrix

  1. Complete §1's table for YOUR context (team, volume, compliance) with NUMBERS: how many deploys/week would 5 microservices mean? How much would the saga cost per flow (how many of your features would become distributed)?
  2. The case in favor: write the best REAL argument for microservices for TicketFlow (not the marketing): which one, and what would have to happen for it to outweigh its cost?
  3. The monolith's case: the counter-argument with the same data: the decision written in 5 lines with its review (48's ADR).

Exercise 2 — The modularization

  1. Reorganize (or draw) your repo into §2's 5 modules: what goes in each and what is left over (24's utils? the shared junk drawer)? The module map with its own language (52: ubiquitous per context).
  2. The public interface: write tickets' and payments' api.py (the public functions and their types). What shows up when writing it (functions crossing modules underneath: the imports the boundary forces up)?
  3. The boundary test: implement the CI test (§2) forbidding from tickets.models in payments/ (and every forbidden combination). Run the CI: how many violators did it catch in YOUR repo? Migrate them to the public interfaces.

Exercise 3 — The contracts between modules

  1. The synchronous one: checkout (payments) calls tickets.reservar(): write the contract test between modules (35 applied to the import: the signature? the exceptions? the summary?). What happens if tomorrow the function changes signature — who catches it?
  2. The asynchronous one: the PaymentSucceeded event (payments→tickets via outbox, 25/30): write the event's contract test (minimum payload? who consumes it and what does it do?). What gets lost making it synchronous (the single transaction? the receiver's coupling)?
  3. The written rule: in docs/adr/, the sync/async choice rule between modules (§3) with the repo's 2 examples as case study. 8 lines.

Exercise 4 — The threshold and the strangle

  1. The 5 thresholds (§4) applied to TicketFlow: which fires first and with which real event (56's PCI? the ×10 volume?)? Write the ADR's trigger with the measurable condition.
  2. The simulated strangle: plan (49: phases with estimate) the extraction of payments: which phases (duplicate with flag? canary? dethrone?) and how much it costs WITH exercise 2's boundary done vs WITHOUT it? The two numbers, the comparison.
  3. The exit plan: the day payments gets extracted: what changes in the repo (the outbox stops being a table and becomes an external stream? 32's saga crosses the network?)? List the 5 architectural changes extraction forces (the ones the prepared boundary already mitigated).

Exercise 5 — Defending the decision

  1. The pitch to the imaginary CTO asking for microservices "because we scale": it is 51's answer: the real metrics (how many replicas does the monolith use today? how many would it need separately?) and the alternative proposal (the modular monolith + the documented trigger?). Max 10 lines.
  2. The new teammate's question: "why not microservices?" — the answer in 3 sentences with the link to the ADR. The test: do they understand it without context?
  3. The close: your personal architecture rule in 3 lines (monolith first? boundary before physics? trigger before fashion?) — paste it into your onboarding (48).

Submit

Paste the matrix with numbers, the public interfaces with the boundary test, the threshold's ADR and the compared strangle plan. Next: Lesson 54 — Resilience.

^ top