System Design Interview Tutorial · Chapter 2

Application design patterns

Deep dives are where you name patterns: outbox, saga, CQRS, circuit breaker. Naming them earns nothing. Interviewers listen for whether you know what each pattern guarantees, what it does not guarantee, and what it costs to run.

One rule ties this chapter together: first decide who owns the authoritative state and which correctness guarantee you need. Then choose the smallest combination of patterns that keeps that guarantee under the failures you must tolerate.

This chapter is the map. The next three chapters cover each level in depth, with mechanisms, diagrams, numbers and real-world examples: low-level primitives, infrastructure building blocks and architectural patterns.

Three levels of design

Patterns work at different scopes, and each level answers a different question:

• Low-level primitives: what can a single operation guarantee under concurrency and failure?
• Mid-level infrastructure: which reusable component gives applications those guarantees?
• High-level architecture: how are business responsibilities, state and interactions organized?

The levels describe the scope of a decision, not a strict stack. Pub/sub and the transactional outbox are infrastructure building blocks; CQRS, event sourcing and sagas are architectural choices. Hexagonal architecture is architectural too, but it governs code dependencies inside one application, not distribution across machines.

Complexity ratings in the tables below: L adds little machinery; M adds a policy or another component; H adds cross-component state, failure recovery or real operational work; VH makes correctness or recovery an ongoing specialist concern. Ratings assume mature databases and middleware, and they rise sharply when patterns interact.

Guarantees to define first

Pick the guarantee before the pattern. Each one is narrower than it sounds:

Database isolation and distributed consistency answer different questions. PostgreSQL's default Read Committed level allows anomalies across statements, and serializable transactions can fail and need retries.

During a network partition, a replicated service cannot both answer linearizably and complete every request at every node. Treat CAP as a decision about which operations wait, which reject, and which tolerate divergence, not as "pick two letters".

The patterns you'll name most

A quick reference for the patterns that come up most in interviews; each name links to its in-depth section. The catalog after it covers the rest.

Patterns compose without implying each other. A saga might use outbox delivery, idempotent consumers and pub/sub, and none of them requires event sourcing.

Low-level primitives

In depth: Chapter 3. Each pattern name below links to its section.

State and concurrency

A row lock in the database that already owns the data is usually simpler than a separate distributed lock. Make a transaction protect the actual invariant, not just wrap the code.

Communication and work ownership

An idempotency key should carry the caller's intent. Hashing the payload is not enough, because two identical requests can both be intended.

Agreement and distribution

Consensus and atomic commit solve different problems: agreeing on replicated state versus committing every participant of a transaction. Neither replaces the other.

Infrastructure building blocks

In depth: Chapter 4. Each pattern name below links to its section.

Serving and resilience

Routing picks a destination; it never authorizes the caller. Hostname routing gives clear ownership at the cost of more DNS, certificates and cross-origin setup. Path routing gives one origin, but shared routing config means coordination and a larger failure domain. Header routing selects versions or experiments without changing the URL, but it is harder to debug, cache keys must include the header, and an untrusted header must never grant access.

Messaging and execution

A queue, a pub/sub topic and a retained log are different consumption models: each job goes to one worker; each subscription gets every message; each consumer tracks its own position in the log. One product can offer several.

Data and performance

Replication copies the same data; sharding splits different data. They solve different scaling problems.

Shared operations

• Service mesh and sidecars standardize transport, identity and telemetry, at the cost of proxy latency and harder diagnosis. A mesh cannot infer business idempotency.
• Identity and authorization belong at every trust boundary. A gateway-only check misses internal access paths.
• Metrics, logs and tracing must propagate context across queues as well as RPCs. A trace is not a durable audit record.
• Backup, restore and failover: replication copies corruption and deletions too, a backup is not proven until you restore it, and failover must fence the old writer.

Architectural patterns

In depth: Chapter 5. Each pattern name below links to its section.

Application structure

CRUD describes data operations; REST describes an interface. A domain command such as CancelOrder works fine on ordinary tables inside one transaction.

Events, queries and workflows

Scatter-gather needs an explicit completion rule: all responses, a deadline, a required subset, or "good enough". Events come in two shapes. A notification ("order 42 changed") forces a follow-up query. Event-carried state ("order 42 shipped to …") lets consumers act alone, at the cost of larger payloads and stronger schema obligations.

Evolution, isolation and geography

CRUD, CQRS, event sourcing and outbox are separate decisions

These four are often blurred together. Each makes one decision:

CQRS can start as two models sharing one database. Event-sourced services usually store current state as snapshots (to rebuild an entity quickly) and projections (to answer queries).

A common misreading: "CRUD update → outbox → archived event log, therefore event sourcing." That sequence does not make the originating service event-sourced. It is a CRUD service with a reliable downstream history. A service is event-sourced only when the event history is the authority that governs its domain changes.

Two valid ways to publish changes, which different services in one application can mix:

• CRUD authority: the command handler commits the business rows and an outbox row in one transaction; a relay publishes the outbox rows.
• Event authority: the command handler validates against the aggregate's state and appends domain events with a version check; a durable subscription publishes them. That can replace a separate outbox, unless publishing is a second, unreliable write.

Both feed the same transport, query projections and consumers. A workflow engine's execution history is not automatically the domain's event store.

Name records by their job, not by the word "event". One database can hold all of these:

Failure cases that decide the design

Outbox and inbox, step by step

An order change must cause an update in another service's database. Walk every crash point:

The outbox closes the local dual-write gap; it is not a promise of delivery through permanent outages or deleted records. Exactly-once effects exist only inside one atomic boundary. A broker's guarantee does not cover your consumer's database, a payment processor or an email.

A saga is not a distributed rollback

Each earlier step has already committed. Compensation is a new business action: a refund leaves a trail, may cost a fee, and can itself fail. Sagas also give no isolation, so other requests see intermediate states; model them explicitly with pending states or reservations.

An orchestrator is logically central but can be replicated and recover from durable state. Choreography removes the coordinator, not the coupling.

Numbers that constrain the design

• A queue does not create capacity. By Little's Law, in-flight work is N = λ × W. At 10,000 operations/s and 0.2 s each, 2,000 are in flight; if latency grows to 2 s at the same throughput, 20,000 are. Admission control and bulkheads bound the damage.
• Backlogs grow at the gap. When arrivals exceed completions, the backlog grows at roughly λ − μ per second until something drops or rejects work. Monitor the age of the oldest message and completion throughput, not just queue length.
• Fan-out multiplies tail latency. If each of n branches is on time with probability p, all are on time with probability pⁿ. At p = 0.99 and n = 100, only about 37% of requests finish on time. Bound fan-out and define partial results.
• Retries multiply. Four nested layers that each try 3 times can send 3⁴ = 81 attempts to the deepest dependency for one request. Retry at one layer and use retry budgets.

When to use what

Start with the smallest design that meets the need and escalate only when a concrete requirement earns the cost:

For asynchronous APIs, 202 Accepted means the work was durably accepted, not finished. Provide a status endpoint, terminal outcomes, and duplicate protection on submission.

A sensible default

Start with a modular CRUD application or a few substantial services, explicit transaction boundaries, deliberate concurrency control, bounded resources, deadlines, and observable recovery (metrics, alerts, tested backups). Then add patterns as needs appear:

• A queue for genuinely asynchronous work.
• An outbox when that work must reliably follow a database commit.
• A cache or derived read view for an observed access problem.
• A workflow engine once durable coordination and recovery recur.
• Separate services where independent ownership, releases, capacity or failure isolation outweigh remote calls and cross-service consistency.

One application can use CRUD for most records, event sourcing for one domain, and sagas for a few cross-service processes.

Example: an order with an external payment. First ask whether order and inventory can share one transaction; if so, use it. No local transaction can include the payment provider, so persist a pending payment, call the provider with a stable operation ID, and reconcile uncertain outcomes. Add orchestration when the flow needs recoverable reservations, timeouts and compensation. None of this requires event sourcing.

In production, every pattern needs an operating plan:

• Migrations: expand, migrate, then contract, so old and new versions coexist. Rolling back code does not undo database changes or external effects.
• Ownership of stuck work: for every asynchronous path, name who owns stalled work, what alerts, and how it is repaired.
• What to track: propagation lag, oldest pending work, dedup hits, failed compensations and rebuild progress, next to user-facing latency and errors.
• Recovery drills: set RPO (acceptable data loss) and RTO (acceptable downtime) targets and test restores; a backup's existence proves nothing.

Using this in the interview

1. State the owner and the guarantee before the pattern: "The order service owns order state; a customer must never be charged twice."
2. Name the smallest pattern and its limit: "An outbox for OrderPlaced; consumers dedupe on the event ID because the relay can resend."
3. Use the deep-dive shape from chapter 1: problem → options → trade-off → pick → what would change your mind.
4. Avoid the classic mistakes: event sourcing for an ordinary CRUD domain, "exactly-once" because the broker says so, sagas described as rollback, a queue to "add capacity", one microservice per table.

Further reading: the AWS cloud design patterns catalog, Martin Fowler on CQRS and Monolith First, transactional outbox, Kleppmann on fencing tokens, The Tail at Scale, and the Google SRE chapter on handling overload.

All chapters