The pattern map: every problem, and the pattern that fixes it
Each microservice pattern fixes one problem and hands you the next. Start from FTGO’s monolith, fix its problems one pattern at a time, and watch the new problems each fix creates.
open problemtrade-off to acceptpattern appliedfast fail / compensation
Why patterns come in chains
A pattern is a reusable answer to a problem in a context. The useful part is what happens after you apply it. Every pattern has a resulting context: benefits, costs, and new problems that need patterns of their own.
Game: fix FTGO, one pattern at a time
FTGO (Food To Go) runs one large monolith. Each card below is a real problem: pick the pattern that fixes it. Some choices are traps that solve a different problem, and the card says why. Some problems have no pattern at all: they are trade-offs you accept and design around.
Fixed problems move to the log, along with the new problems each pattern caused. Click any pattern name in the log for its full card.
What happened
All 45 patterns, by the problem they solve
The same patterns, grouped the way the book groups them. Green ones are those you used in the game. Click a pattern to see its problem, solution and cost, and the chain around it: what made it necessary, and what it leads to.
Type a symptom (“slow”, “twice”, “who is the user”) or a pattern name to filter.
Lab: a hung service, without and with a circuit breaker
Order Service calls Payment Service synchronously. Order has a pool of 10 request threads and waits up to 30 seconds for each reply. Send 20 orders and watch the pool.
The problem is not that Payment is down. It is that Order goes down with it.
Press “Send 20 orders”.
Lab: a crash between saving and publishing
Order Service must save the order and tell Kitchen about it. The database and the broker cannot share one transaction. Pick a failure and see what survives.
The fix is to stop writing to two places: write only to the database, and let a relay move the message.
Lab: a failed step, without and with a saga
Creating an order touches four services, each with its own database. Pick the step that fails.
A saga does not prevent failure. It makes sure every step that already changed data is undone by a compensating step.
Quick check: name the pattern
8 questions. Pick one answer each.
Recap
- Microservices fix the monolith’s delivery and scaling problems and create a dozen new ones. Most of the pattern language exists to handle those.
- Data has the longest chains: database per service → saga → domain events → outbox → relay; and database per service → API composition → CQRS.
- Some problems have no pattern: saga isolation, a CQRS view that lags, duplicate messages. You accept them and design around them.
- When you suggest a pattern in an interview, name the problem it fixes and the problem it creates.
Microservice patterns: common questions
Which microservice pattern solves distributed transactions?
The saga pattern: a sequence of local transactions, one per service, with compensating transactions that undo earlier steps when a later one fails.
How do you publish an event reliably when you update a database?
Use the transactional outbox: insert the message into an outbox table in the same transaction, then relay it to the broker by polling or transaction log tailing.