System Design Quick Reference
This quick reference condenses the recurring building blocks of system design — scaling techniques, caching strategies, database choices, and distributed-systems tradeoffs — into a single scannable summary. It is not a substitute for understanding *why* each choice applies (see the dedicated topics on each subject); it's meant to be reviewed shortly before an interview or design discussion to refresh which tool maps to which problem, and to spot-check that a proposed design hasn't overlooked an obviously relevant technique.
Cricket analogy: This is like a cricketer's pocket cheat-sheet of field placements and bowling matchups reviewed just before walking out to bat — it doesn't replace years of practice but refreshes which tactic fits which situation.
Scaling and traffic handling
Vertical scaling (bigger machine) is the simplest first step but has a hard ceiling and a single point of failure; horizontal scaling (more machines) is what enables systems to grow beyond that ceiling but requires the workload to be partitionable and typically requires the service layer to be stateless. Load balancers (round robin, least connections, or consistent-hashing-based) distribute traffic across horizontally-scaled instances; auto-scaling reacts to load metrics to add/remove capacity dynamically. For reads, caching (in-memory stores like Redis, or CDN edge caching for static/semi-static content) is almost always the highest-leverage optimization given that most systems are read-heavy.
Cricket analogy: Vertical scaling is like training one star all-rounder harder; horizontal scaling is like recruiting more players onto the squad, requiring a captain (load balancer) to rotate them fairly, with a selection committee (auto-scaling) adding players as tournament demand rises, while a warm-up net session (cache) speeds up most pre-match prep.
Data layer decisions
Choose SQL when data is relational, requires multi-row transactions, or benefits from a fixed, well-understood schema and strong consistency guarantees; choose NoSQL (key-value, document, wide-column) when the access pattern is simple key-based lookups at very large scale, the schema needs to be flexible, or horizontal write scaling matters more than relational features. Indexing speeds up reads at the cost of slower writes and extra storage — index the columns actually used in WHERE/JOIN/ORDER BY clauses, not everything. Replication (leader-follower for read scaling and failover; multi-leader or leaderless for write availability across regions) and sharding (partitioning data across nodes by a key, often via consistent hashing) are the two primary techniques for scaling storage beyond a single node.
Cricket analogy: Choosing SQL is like a formal Test match ledger needing multi-innings transactions; choosing NoSQL is like a T20 league needing simple, massive-scale score lookups; indexing a scorecard by player name speeds searches but slows updates; replication mirrors the scoreboard for backup umpires while sharding splits records by season.
Quick decision table:
Problem -> Default first tool to consider
---------------------------------------------------------------------
Read-heavy hot data -> In-memory cache (Redis) + CDN
Write-heavy, simple key lookups -> NoSQL, sharded by key hash
Complex relational queries/joins -> SQL with read replicas
Need to scale reads only -> Leader-follower replication
Need to scale writes -> Sharding (consistent hashing)
Async decoupling between services -> Message queue (Kafka/SQS)
Broadcast one event to many consumers -> Pub/sub
Protect a service from overload -> Rate limiter (token bucket) + circuit breaker
Cross-node coordination/leader election -> Consensus algorithm (Raft/Paxos)
Strong consistency required -> Favor CP design, accept availability cost during partitions
Availability is paramount -> Favor AP design, accept eventual consistencyDistributed systems tradeoffs at a glance
The CAP theorem says that during a network partition, a distributed system must choose consistency or availability — it cannot have both. Consistency models range from strong (every read sees the latest write) to eventual (reads may return stale data temporarily but converge). Idempotency (designing operations so repeating them has the same effect as doing them once) is essential wherever retries can occur, which in distributed systems is essentially everywhere. Consensus algorithms (Raft, Paxos) let a cluster of nodes agree on a single value or leader despite failures, underpinning distributed locks, leader election, and strongly consistent replicated logs.
Cricket analogy: CAP theorem is like a rain-hit match where the umpires must choose between waiting for a perfectly accurate DLS recalculation (consistency) or restarting play immediately with an approximate target (availability); idempotency is like a scorer re-entering the same run twice without doubling the total, and consensus algorithms are like the third umpire and two on-field umpires agreeing on one decision via review.
When reviewing a design under time pressure, a fast sanity check is to trace one request end-to-end through the diagram and ask at each hop: 'what happens if this component is slow or unavailable right now?' This single habit surfaces missing caching, missing retries/timeouts, and missing failover far faster than reviewing the diagram holistically.
This reference is intentionally compact — don't mistake memorizing the decision table for understanding the tradeoffs. An interviewer who hears 'I'd use a message queue here' without a reason (decoupling? buffering bursty load? enabling async retries?) will treat it as a red flag, not a strength. Use this page to jog memory of the option space, not as a substitute for reasoning through the specific problem.
- Horizontal scaling plus caching are the two highest-leverage general-purpose techniques for handling growing read-heavy traffic.
- Choose SQL for relational/transactional needs and strong schema guarantees; choose NoSQL for simple, massively-scalable key-based access with flexible schema.
- Replication scales reads and provides failover; sharding scales writes and storage by partitioning data across nodes.
- The CAP theorem forces a consistency-vs-availability choice specifically during network partitions, not at all times.
- Idempotency is a required property for any operation that might be retried, which is virtually every operation in a distributed system.
- This cheat sheet is a memory aid for the option space, not a replacement for reasoning about which tradeoff fits a specific problem's actual requirements.
Practice what you learned
1. According to the quick-reference decision table, what is the default first tool to consider for read-heavy hot data?
2. What is the primary distinction driving the choice between replication and sharding?
3. According to the CAP theorem as summarized here, when must a distributed system choose between consistency and availability?
4. Why is idempotency described as essential in distributed system design?
5. What is the risk explicitly warned about in using this quick reference during an interview?
Was this page helpful?
You May Also Like
The CAP Theorem
A foundational result stating that a distributed data store can only guarantee two of consistency, availability, and partition tolerance at once, shaping every distributed database's design.
SQL vs NoSQL Tradeoffs
Compares relational and non-relational databases across schema flexibility, consistency, scalability, and query capability to guide selection for a given workload.
Common System Design Mistakes
A catalog of recurring architectural and interview mistakes — over-engineering, ignoring tradeoffs, false precision, and skipping requirements gathering — with how to avoid each.
Database Sharding
Explains how sharding partitions a dataset horizontally across multiple database nodes to scale beyond what a single machine can hold, and the tradeoffs of common sharding strategies.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics