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.

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.

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.

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.