Twelve patterns that reappear in every design
Most design problems are one of a dozen shapes wearing a product name.
What you will be able to do
- Map a novel problem onto a known pattern
- Explain the cost of precomputation versus computation at read time
- Recognise when CQRS or an outbox is the missing piece
- Combine patterns without contradicting one another
The catalogue
| Pattern | Solves | Cost |
|---|---|---|
| Precomputed feed (fan-out on write) | Fast timeline reads | Expensive/awkward for celebrities |
| Fan-out on read | Cheap writes, one timeline per viewer | Read amplification |
| CQRS | Different read and write shapes | Lag between models |
| Transactional outbox | Guaranteed event publication | Relay to operate |
| Saga | Multi-service workflow without a distributed transaction | Compensations, intermediate states |
| Idempotency key | Safe retries | Store of keyed outcomes |
| Write-ahead log | Durability and replication | Recovery time |
| Read repair | Divergent replicas | Background reads and comparisons |
| Consistent hashing | Rebalancing when nodes change | Virtual nodes and complexity |
| Sharding by key | Horizontal scale beyond one node | Cross-shard queries |
| Circuit breaker | Cascading failure | Fallback design |
| Cold tiering | Storage cost | Retrieval latency |
Patterns as questions
Each pattern answers a question. Read rate high and data changing rarely? Precompute. Writes spread across many services and someone must know the truth? Outbox. Reads and writes want different schemas? CQRS. Cross-service business transaction? Saga with compensations. These are the same three sentences every time, applied to a different noun.
Worked example: notifications
A notification service takes events, decides who to notify, renders a channel-specific message, and delivers with retries. Patterns: fan-out on read of preferences, a queue per channel for rate limits, idempotency keys so a retry does not double-send, a dead-letter queue for permanent failures, and a deduplication window of minutes.
That is five patterns in four sentences because they answer different questions: who, how fast, how often, what if it fails, and what if it fails twice. Being able to decompose a problem this way is worth more than naming more tools.
Worth remembering
- Precompute what is read constantly and changes rarely; compute what is read rarely or must be exact.
- A write-ahead log is the basis of durability, replication and replay — one idea, three uses.
- CQRS separates the write model from read models, at the cost of eventual consistency between them.
- Patterns compose, but two conflicting consistency choices in one design is a bug, not a nuance.