System Design Examples

Saga pattern: designs that hold up under hostile review

A saga coordinates a multi-service business flow as local transactions + compensations, not as distributed ACID. The interesting part is not listing industries that "use sagas" — it is tracing failure, naming the pivot, and rejecting the wrong tool (local txn or 2PC) when it would win.

Worked example: food delivery (orchestrated)

Order 8842, total $27.50, restaurant r-119. Orchestrator = Order service.

#	Step	Local commit	Result
T1	Create order	status=PENDING	OK
T2	Authorize payment	$27.50 hold (authId=A7)	OK
T3	Confirm restaurant	ticket=K42 reserved	OK
T4	Assign courier	search 90s	FAIL — none available
C3	Release restaurant	cancel K42	OK
C2	Void auth	void A7	OK
C1	Cancel order	CANCELLED / NO_COURIER	OK

Design choices that matter: authorize-then-capture so C2 is a clean void; courier assignment before capture so you can still compensate money; after courier en-route + capture you pass the pivot — only roll forward.

Travel booking (multi-party)

Flight + hotel + car across vendors. Often choreography or a booking orchestrator with timeouts. Compensations are vendor-specific cancel APIs (sometimes with fees). First bottleneck: long-held vendor reservations under inventory contention. Rejected alternative: 2PC across airline APIs — they will not hold XA locks for your cart.

E-commerce checkout

Order → Payment → Inventory → Shipping. Same saga shape. Inventory failure after payment hold → void/refund compensation. Paid trade-off: user may briefly see "processing" and inventory systems see PENDING holds (no isolation) — so downstream consumers must treat PENDING as a semantic lock: reporting excludes it, fulfilment won't pick it, and a second saga touching the same SKU either waits or fails fast rather than double-committing.

Banking — the corrected lesson

Transfer $500 savings→checking inside one bank is one local ACID transaction, not a saga:

BEGIN;
  UPDATE accounts SET balance = balance - 500
    WHERE id = 'savings' AND balance >= 500;
  -- if 0 rows were updated: insufficient funds -> ROLLBACK and stop
  UPDATE accounts SET balance = balance + 500 WHERE id = 'checking';
COMMIT;

The affected-row check is load-bearing: without it, an insufficient-funds transfer debits nothing but still credits $500 — the transaction is atomic, yet the invariant breaks, because ACID never checks business rules you didn't express. (A CHECK (balance >= 0) constraint is the belt-and-braces version.) Same idiom, same guard, as the stock reservation in the worked saga example.

Model as saga only for inter-bank or truly split services/databases. Using saga "because there are two steps" is an architecture smell.

Hostile design-review table

Scenario	First bottleneck / failure	Rejected alternative	Trade-off paid
Food delivery order	Courier SLA miss mid-saga; compensation latency	Single DB for restaurant+courier+pay (ownership/scale fights)	No isolation; SMS may fire before pivot if ordered wrong
Travel multi-vendor	Partial books + cancel fees; orchestrator crash state	2PC across vendors	Eventual consistency; complex compensations
Intra-bank transfer	—	Saga itself (wrong tool)	N/A — use local ACID
Choreography-only checkout >5 steps	Impossible incident narrative ("who owns step 4?")	Keep pure choreography for purity	Prefer orchestrator for visibility

When NOT to use a saga

• Data co-located in one database → local transaction.
• Small set of XA resources, one trust domain, correctness ≫ availability → consider 2PC.
• Cannot write real compensations (irreversible side effects early) → redesign step order / pivot.
• Team cannot operate durable orchestrator state + idempotent handlers → you will leak money/inventory.

Operability

• Persist saga state; resume after orchestrator crash.
• Metrics: sagas stuck in non-terminal state, compensation failure rate, time-to-compensate.
• Every compensation idempotent (voiding A7 twice = no-op).

Drill ladder

1. Q: Why authorize-then-capture in the food example? A: Compensation is void of hold, not refund of captured funds — simpler, faster, less customer pain.
2. Q: Orchestrator dies after C3 succeeds, before C2. What must exist? A: Durable saga log/state machine that resumes compensation from last completed step.
3. Q: Is "debit + credit" always a saga? A: No — only if accounts are in separate transactional domains.

I just read a lesson on **System Design Examples** (System Design) and want to truly understand it. Explain System Design Examples from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **System Design Examples** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **System Design Examples** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **System Design Examples** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.