System Design Cheat Sheet: The One-Page Reference Senior Engineers Actually Use

System design interviews reward two things: recognizing patterns fast, and being specific about trade-offs. This cheat sheet is the dense reference I wish I had taped to my monitor the week before every senior loop. It is not a textbook. Every section is meant to be readable in under a minute, and the whole thing is meant to be reviewed start-to-finish the morning of your interview.

If you want to drill the concepts below with a real interviewer, we built AI system design mock interviews that score you on the same rubric FAANG uses. But first, the cheat sheet.

#The interview framework (use this every time)

Every system design interview follows roughly the same seven steps. If you walk in with this skeleton, you will never freeze.

1. Clarify requirements. Functional (what does the system do?) and non-functional (latency, throughput, consistency, availability, durability). Pin down the read/write ratio early.
2. Back-of-envelope estimation. Users, QPS, storage, bandwidth. Two or three numbers, not twenty.
3. API sketch. List the three or four endpoints that matter. Method, path, request, response.
4. Data model. Name the core entities and their relationships. One line per entity.
5. High-level diagram. Client → load balancer → stateless app tier → data tier. Add caches, queues, and external services only where they earn their place.
6. Deep dive on the bottleneck. The interviewer will pick one area. Usually the database or the hottest component. Have your decision matrix ready.
7. Evolve. What breaks at 10x scale? What are the failure modes? What would you add with another quarter of engineering?

#Back-of-envelope numbers (memorize these)

These are the 2026-updated latency numbers every senior engineer should have on reflex. They are not from a single source — they are the rounded consensus across recent Google, Amazon, and academic papers.

Storage back-of-envelope:

• 1 KB/user for profile = 1 GB per million users
• 1 MB/post × 100 posts × 1M users = 100 TB (this is why image/video services dominate cost)
• 1 ns = 10⁻⁹ s · 1 μs = 10⁻⁶ s · 1 ms = 10⁻³ s

Traffic back-of-envelope:

• Twitter/X averaged ~6,000 tweets per second at peak. That is ~500M tweets/day.
• A service with 100M DAU and each user making 10 requests/day = 1B requests/day ≈ 12K QPS average, ~50K QPS peak.
• Rule of thumb: peak QPS = 3–5× average QPS.

#Core building blocks (what each one is for)

#Load balancer

Distributes traffic across a stateless application tier. Layer 4 (TCP) is faster and simpler. Layer 7 (HTTP) lets you route on headers, cookies, paths. Use Layer 7 when you need canary deploys, blue/green, or path-based routing.

#Reverse proxy

Nginx, Envoy, HAProxy. Terminates TLS, adds compression, caches static content, rate limits, and authenticates. Often fused with the load balancer in cloud managed services (ALB, CloudFront).

#CDN

Caches static assets at edge POPs close to users. Essential for any service with global users and static content. Modern CDNs (CloudFront, Fastly, Cloudflare) also run edge compute.

#Application server (stateless)

The layer you can scale horizontally by adding boxes. Any state lives in databases, caches, or session stores — never on the app server itself.

#Cache

Redis or Memcached. Sub-millisecond reads. Use for hot data, session stores, rate limit counters, leaderboards. See the caching strategies section below for how to populate and invalidate.

#Database (OLTP)

The system of record. The first bottleneck in 90% of system design interviews. Pick wisely — see the data store decision matrix below.

#Object storage

S3, GCS, Azure Blob. Cheap, durable, infinite. Use for blobs: images, videos, backups, logs. Not for structured queryable data.

#Message queue

Kafka, RabbitMQ, SQS, Pub/Sub. Decouples producers from consumers and absorbs traffic spikes. The difference between queues and event logs matters — see below.

#Coordination service

ZooKeeper, etcd, Consul. Used by leader election, distributed locks, service discovery, configuration. You almost never build these yourself, you rent them from a platform.

#Data store decision matrix

This is the question interviewers love most. Know the trade-offs cold.

The 80/20 rule. In the vast majority of interviews, the right answer is "a relational database with read replicas, with a Redis cache in front, and object storage for blobs." You only deviate when the requirements force you to: extreme write throughput (wide-column), single-key access patterns at massive scale (key-value), or search (Elasticsearch).

#Consistency models (pick the weakest that meets the requirement)

Rule: Strong consistency is expensive. Every unnecessary strong guarantee limits throughput, increases latency, and reduces availability. Ask the interviewer what the user experience actually requires before picking.

#CAP and PACELC in one paragraph

CAP says during a network partition, you must choose between consistency and availability. PACELC adds: and even when there is no partition, you still choose between latency and consistency. Most systems are either CP/EC (Spanner, HBase) or AP/EL (Cassandra, Dynamo). When an interviewer asks "CAP?", the right answer is never just "I pick AP" — it is "this use case tolerates eventual consistency for X reason, so I am optimizing for availability and latency."

#Caching strategies

Invalidation. There are two hard problems in computer science. Cache invalidation is one. Strategies: TTL expiry (simplest), write-through (expensive but correct), event-driven invalidation via CDC (complex but accurate). TTL is the answer in 80% of interviews — pick a TTL based on how stale the data can be for your use case.

#Sharding and partitioning

Three main strategies:

Range-based. Partition by a key range, e.g. user IDs 0–1M on shard A, 1M–2M on shard B. Simple but creates hotspots when traffic is uneven.

Hash-based. Hash the partition key and mod by number of shards. Distributes evenly but makes range queries hard and rebalancing painful.

Consistent hashing. Hash both keys and nodes onto a ring. Each key lives on the next node clockwise. Adding a node only moves 1/N of the keys. Used by Cassandra, DynamoDB, memcached clients.

Directory-based. A lookup service maps keys to shards. Flexible but adds a single point of failure.

#Replication

Leader-follower (single-leader). One node accepts writes, replicates async or sync to followers. Simple, strong consistency if you read from leader. Postgres, MySQL, Redis default.

Multi-leader. Multiple nodes accept writes, replicate to each other. Low write latency for users near a leader. Conflict resolution required. Used for multi-region active-active.

Leaderless. Any node accepts any operation. Quorum reads/writes (R + W > N) guarantee consistency. Used by Dynamo, Cassandra, Riak.

Quorum math: With N replicas, W writes, R reads:

• W + R > N → strong consistency
• W = N → strong consistency on read from any replica, but no availability under failure
• R = 1, W = 1 → fast but weak, conflicts allowed

#Messaging: queues vs event logs

Queue (RabbitMQ, SQS). Messages are consumed and removed. Good for task distribution, work queues, async jobs.

Event log (Kafka, Pulsar, Kinesis). Messages are retained for a window. Multiple consumers read independently from their own offset. Good for event sourcing, audit trails, fan-out analytics, replay.

Delivery guarantees:

• At-most-once. Fire and forget. Fastest, can drop messages.
• At-least-once. Redelivery on failure. Standard default. Consumers must be idempotent.
• Exactly-once. Requires transactional producers or deduplication on the consumer. Kafka supports this end-to-end within Kafka.

Idempotency is your friend. In any message-driven system, design consumers to handle duplicate deliveries by key. This is cheaper than hunting exactly-once semantics.

#Rate limiting algorithms

Token bucket is the most common answer and the right default. It allows bursts (good UX) while still enforcing an average rate.

#API design: REST vs GraphQL vs gRPC

#Common distributed systems patterns

CDC (Change Data Capture). Stream database changes to downstream systems (search, analytics, caches). Debezium, AWS DMS. Much safer than dual writes.

Outbox pattern. Write the event to the same DB transaction as the business change, then a separate process ships it to the message bus. Solves the "dual write" problem.

Saga. Break a distributed transaction into a sequence of local transactions, each with a compensating undo. Used in e-commerce order flows, travel booking.

CQRS (Command Query Responsibility Segregation). Separate write model and read model. Write model is normalized, read model is denormalized and optimized for queries. Often paired with event sourcing.

Event sourcing. Store every state change as an immutable event. Current state is derived by replaying events. Great for auditability and time-travel debugging. Complex to refactor.

Idempotency keys. Client sends a unique key with each mutation. Server stores the key with the result. Replays return the original result. Essential for payment APIs.

Circuit breaker. Wrap external calls. After N failures, open the circuit and fail fast for a cooldown. Prevents cascading failures.

Bulkhead. Isolate resources so one slow dependency cannot exhaust all your threads. Named after ship compartments.

#Observability: the three pillars

Metrics. Numbers over time. Counters, gauges, histograms. Good for dashboards and alerts. Prometheus, Datadog, CloudWatch. Cheap to store.

Logs. Discrete events with context. Good for debugging after the fact. Expensive to store at scale — use sampling.

Traces. End-to-end request flows across services. Essential for latency debugging in microservices. Jaeger, Tempo, OpenTelemetry.

The 2026 consensus is: emit metrics for everything, emit structured logs for errors and key events, enable distributed tracing at 1–10% sampling, and pay for full traces only on errors.

#Numbers every senior engineer should know

• A single Postgres instance: ~50K QPS simple reads, ~5K QPS writes, ~1 TB data before sharding pain.
• A single Redis instance: ~100K ops/sec, sub-millisecond.
• A single Kafka broker: ~100 MB/sec throughput per partition.
• S3 first-byte latency: ~10–20 ms.
• Cross-region round trip: 50–200 ms.
• 99th percentile of a read-heavy API should be under 200 ms for good UX.
• "Three nines" (99.9%) = 8.76 hours downtime per year. "Four nines" = 52 minutes. "Five nines" = 5 minutes.

#The 15-minute diagram template

When the interviewer says "design X," sketch this skeleton first, then justify each box:

        [Clients: web, mobile, API consumers]
                       |
                  [CDN / Edge]
                       |
              [Load balancer / API gateway]
                       |
            [Stateless app servers] ←→ [Auth service]
              /    |    \
      [Cache]  [Primary DB] ←→ [Read replicas]
                       |
                 [Message queue]
                       |
         [Async workers] → [Object storage]
                       |
              [Search / Analytics]

Nine boxes. Every real system is some variation of this. The interview is about which boxes you keep, which you merge, and which you defend under scaling questions.

#What the interviewer is actually scoring

Most candidates think the interview is about drawing the right diagram. It is not. Senior and staff loops score you on five axes:

1. Problem framing. Did you clarify requirements and priorities before designing?
2. Trade-off awareness. Did you name alternatives and explain why you picked one?
3. Scale reasoning. Did you estimate QPS, storage, and bandwidth before committing to a design?
4. Failure modes. Did you think about what happens when a component dies?
5. Communication. Did you stay organized, invite questions, and keep the interviewer with you?

A candidate who draws a perfect diagram silently will be ranked lower than one who draws a slightly imperfect diagram while narrating trade-offs and inviting the interviewer to redirect.

#FAQ

#Print this, review the morning of

This cheat sheet is designed to be read front-to-back in about 15 minutes the morning of your interview. The goal is not to learn new concepts on interview day — it is to refresh your mental index so the right pattern surfaces fast when the interviewer asks the question.

If you want to drill the frameworks here against a real interviewer that scores you on the same rubric FAANG uses, the ProTechStack AI system design mock interview gives you unlimited sessions with detailed per-round feedback. Free accounts get one session per month; the interview question library at /interview is free and unlimited.

Next in this series: the Coding Interview Patterns Cheat Sheet covers the 20 recognizable patterns that solve 90% of coding problems. Bookmark both.