A trade-off cheat sheet
Every trade-off in this chapter on one page, plus a drill for stating the choice, the gain, and the cost in a single fluent sentence.
How to use this
By now you have the exchanges. The interview skill is recalling the right one instantly and stating it cleanly — choice, gain, and cost — in one breath. This is the one-page index, then a drill to make it fluent. It’s the capstone before you apply all of it to real systems in Chapter 4.
The master table
| Trade-off | Pick A when… | Pick B when… |
|---|---|---|
| Strong vs eventual consistency | A read must see the latest write (money, inventory) | Staleness is harmless (feeds, counts) — buys latency + availability |
| Latency vs throughput | Interactive path; p99 matters | Bulk/background; total volume matters |
| ACID vs BASE | Invariants must hold; transactions | Scale + availability over strict freshness |
| Read-through vs write-through | Read-heavy; lazy-load + TTL | Writes must be instantly visible |
| Batch vs stream | Completeness over freshness; cheaper | React in real time; freshness over cost |
| Load balancer vs API gateway | Spread load across identical servers | Manage auth/routing/limits across services |
| Gateway vs direct exposure | Many services/public API; central control | Internal calls; avoid the extra hop |
| Proxy vs reverse proxy | Acting for clients (egress, filtering) | Acting for servers (LB, TLS, caching) |
| Gateway vs reverse proxy | Need API awareness (auth, quotas, aggregation) | Just TLS/caching/load-balancing |
| SQL vs NoSQL | Transactions, joins, strong consistency | Scale, flexible schema, known access patterns |
| Primary-replica vs P2P | Simple consistency; read scaling | Write availability; no single bottleneck |
| Compression vs dedup | Redundancy within an item | Redundancy across items (often both) |
| Server- vs client-side cache | Shared hot data; need invalidation control | Eliminate the request; static/own data |
| REST vs RPC | Public, cacheable, resource CRUD | Internal, high-perf, typed, streaming |
| Polling/WS/webhooks | Match direction + frequency | (server↔server async → webhooks) |
| CDN vs origin | Static/cacheable, wide audience | Dynamic, personal, must be fresh |
| Serverless vs servers | Spiky/event-driven; pay-per-use | Steady load; stateful; latency-critical |
| Stateful vs stateless | Inherent state (DB, sockets) — contain it | App/API tier — push state to a shared store |
| Hybrid vs all-cloud | Compliance/latency/existing DC | Elasticity, simplicity, greenfield |
| Token vs leaky bucket | Tolerate bursts, cap average | Enforce a strictly smooth rate |
| Read-heavy vs write-heavy | Cache + replicas + denormalize | Shard + queue + write-optimized store |
The one-sentence formula
Every trade-off statement should have three clauses:
“I’ll [choice], which [gain], at the cost of [cost] — acceptable here because [requirement].”
Examples:
- “I’ll serve the feed from read replicas, which scales reads and cuts latency, at the cost of eventual consistency — fine because a few seconds of staleness is invisible in a feed.”
- “I’ll shard the events table by user id, which removes the single-primary write bottleneck, at the cost of cross-shard analytics needing scatter-gather — acceptable because reporting is offline and batched.”
- “I’ll rate-limit with a token bucket, which tolerates natural bursts while capping the average, at the cost of brief over-limit spikes — fine for a public API.”
Drill: complete the sentence
For each, name choice + gain + cost out loud:
- A photo-sharing app’s image delivery → CDN: edge latency + origin offload, at the cost of cache-invalidation (solved with versioned URLs).
- A bank’s ledger writes → ACID/strong + CP: correctness, at the cost of latency and refusing writes during a partition — required for money.
- A metrics ingestion pipeline → write-optimized + queue + stream: write throughput and freshness, at the cost of eventual consistency and pipeline complexity.
- A chat app’s message transport → WebSockets: low-latency bidirectional push, at the cost of stateful connections needing a pub/sub backplane.
The takeaway
There is no “right” architecture — only the one whose costs you chose on purpose. If you can attach the three-clause sentence to every major decision, you will sound like someone who has built systems, not memorized them. Now take it to Chapter 4 and design real ones.