System Design Interview Cheat Sheet: Patterns & Formulas
System design interviews evaluate a candidate's ability to architect scalable, resilient, and cost-effective distributed systems under real-world constraints. Success requires mastering back-of-the-envelope capacity estimations, understanding hardware latency numbers, and selecting appropriate architectural patterns for data storage, caching, and load distribution.
This cheat sheet serves as a definitive reference for engineering interviews and production system design, summarizing essential estimation formulas, latency numbers every programmer should know, and core distributed systems patterns.
Latency Numbers Every Programmer Should Know
Accurate back-of-the-envelope calculations require memorizing fundamental hardware and network latency magnitudes. Comparing L1 cache access times (nanoseconds) with network round-trips across oceans (milliseconds) informs decisions on caching layers, database indexing, and edge computing deployment.
When designing high-throughput APIs, minimizing disk I/O and network hops is paramount. For instance, reading 1 MB sequentially from RAM takes ~250 microseconds, whereas reading 1 MB sequentially from a fast NVMe SSD takes ~1,000 microseconds, and an internet packet round-trip from California to Europe takes ~150 milliseconds.
Quick reference
- Memory (RAM) access is ~10,000x faster than disk access; always place hot metadata in Redis or in-memory caches.
- An internet round-trip across continents adds 150ms of unpreventable latency; deploy CDN edge points for global users.
- Assume 86,400 seconds per day (~100,000 for simplified mental estimation during quick interview calculations).
Remember this
Memorizing latency magnitudes allows you to quickly justify architectural choices like caching, CDN placement, and database selection.
Capacity Estimation & Storage Calculation Rules
Back-of-the-envelope calculations demonstrate technical maturity during system design interviews. Interviewers evaluate whether candidates can translate product requirements (e.g., '10 million daily active users uploading 2 photos per day') into concrete bandwidth, QPS, and storage disk requirements.
A helpful rule of thumb: 1 million daily active users issuing 10 requests per day generates ~115 average QPS. At peak load (typically 2x average), plan for ~230 peak QPS. Multiply peak QPS by request payload size to determine network ingress and egress bandwidth.
Quick reference
- 1 Million Requests / Day ≈ 12 Requests / Second (10,000,000 requests/day ≈ 115 QPS).
- Always calculate storage for a 5-year retention period to evaluate long-term database sharding needs.
- Account for database index overhead (add 20–30% to raw storage estimates) and replica multiplier (3x for primary-replica setups).
Remember this
Translate user metrics into QPS, peak bandwidth, and 5-year storage projections to justify database sharding and caching strategies.
Core Architectural Decision Matrix for Interviews
Every system design trade-off maps back to fundamental computer science principles: Consistency vs. Availability (CAP Theorem), SQL vs. NoSQL (Database Selection), and Polling vs. WebSockets (Real-Time Communications).
When designing high-throughput applications, apply layered defense: place a global CDN in front of an L7 Load Balancer, route read requests through Redis caches using Cache-Aside patterns, write mutative events to Kafka queues via the Transactional Outbox pattern, and execute async worker jobs across stateless microservices.
Quick reference
- Use Load Balancers (L4 for TCP level, L7 for HTTP routing) to distribute incoming traffic across stateless worker instances.
- Implement Rate Limiting (Token Bucket or Leaky Bucket algorithms) at the API Gateway to protect downstream microservices.
- Decouple synchronous write operations using message queues (Kafka or RabbitMQ) for asynchronous worker processing.
Remember this
Building scalable systems requires combining CDN edge caching, L7 load balancing, database sharding, and asynchronous event queues.
Key takeaway
Mastering system design requires combining back-of-the-envelope estimation formulas, latency awareness, and proven architectural patterns. By evaluating capacity requirements upfront and selecting appropriate caching, database, and messaging layers, developers build resilient systems that perform under enterprise traffic loads.
Related Articles
Explore this topic