System Design Interview Cheat Sheet — Save This Page

Most engineers walk into a system design interview knowing the components. They fail because they can't recall the numbers fast enough, apply the wrong consistency model, or pick an API style without justification. This system design cheat sheet fixes that — every framework, every benchmark, and every decision rule on one page, in the exact format you need mid-interview.

Keep this open during your final prep week. Screenshot the tables. The goal is instant recall, not re-reading.

System Design Cheat Sheet: Estimation Formulas and Numbers

Interviewers use estimation to test whether you have intuition about scale. Get this wrong and the rest of the design looks shaky, regardless of how elegant your architecture is.

The powers-of-two anchor table — memorise these, everything else derives from them:

| Unit | Bytes | What fits | |---|---|---| | 1 KB | 10³ | 5 tweets, 2 user records | | 1 MB | 10⁶ | 1 medium photo, 2,000 web pages | | 1 GB | 10⁹ | 1 compressed movie, 1M user records | | 1 TB | 10¹² | 1,000 movies, entire SQL DB for a mid-size product | | 1 PB | 10¹⁵ | All of YouTube's daily uploads × 3 |

The five estimation formulas you run in every interview:

Peak QPS       = (Daily Requests ÷ 86,400) × Peak Multiplier
Storage/year   = Writes/day × Object size × 365
Bandwidth      = Peak QPS × Avg response size
Cache size     = Hot read QPS × Avg response × TTL × (1 - cache hit rate)
Servers needed = Peak QPS ÷ Requests per server (typically 1,000–5,000 req/s for typical API)

Peak multipliers to apply by domain:

| System type | Multiplier | Why | |---|---|---| | Normal web product | 2–3× | Daily variation, lunch/evening peaks | | Food delivery (morning rush) | 5× | Geographic burst at 1–2 specific hours | | Flash sale / IPL match | 10–20× | Hard-to-predict spike, design for 20× | | Payment gateway | 1.5–2× | Spread through the day |

Worked estimates for common interview problems:

| Problem | DAU / volume | Peak QPS | Storage/yr | |---|---|---|---| | Twitter/X (500M tweets/day) | 300M DAU | ~17K avg, 50K peak | ~50 TB | | WhatsApp (100B messages/day) | 2B DAU | ~1.2M | ~10 PB | | Swiggy at scale (5M orders/day) | 50M DAU | ~170 avg, 1K peak | ~10 GB | | YouTube (100K uploads/day, 10 GB avg) | 2B DAU | ~1 for writes | ~350 PB/yr | | Instagram Stories (500M/day, 50 KB avg) | 500M DAU | ~6K | ~9 TB |

Latency Numbers and Throughput Benchmarks

Every system design decision is a latency bet. These numbers tell you whether the bet pays off.

Latency reference: hardware to network

| Operation | Latency | Order of magnitude | |---|---|---| | L1 cache access | 1 ns | Baseline | | L2 cache access | 4 ns | 4× L1 | | Main memory (RAM) read | 100 ns | 100× L1 | | SSD random read | 100 µs | 100,000× L1 | | HDD seek | 10 ms | 10,000,000× L1 | | Redis GET (local) | 0.1 ms | Sub-millisecond | | Intra-datacenter network | 0.5–1 ms | Design within this | | Cross-region (Mumbai → US) | 100–150 ms | Never in hot path | | Cross-continent round trip | ~150 ms | Budget for user perception |

The ratios that matter:

• RAM is 1,000× faster than SSD. Cache anything read-heavy enough to justify memory cost.
• SSD is 100× faster than HDD. HDD is only for cold archival in 2026.
• Human perceives < 100ms as instantaneous. Your p99 API latency budget is ~50ms if you want to ship a fast product.

Throughput benchmarks: what production systems actually handle

These are the numbers that separate candidates who've thought about production from those who only read blog posts.

| Component | Typical throughput | Notes | |---|---|---| | Nginx (HTTP) | 50K–100K req/s per instance | Single bare-metal box | | PostgreSQL | 5K–15K queries/s | Tuned, indexed, connection pooled | | MySQL | 10K–30K queries/s | With read replicas | | Redis | 100K–1M ops/s | In-memory, single-threaded | | Kafka | 1M+ messages/s per broker | With replication factor 3 | | Cassandra write | 50K–100K writes/s per node | Log-structured, sequential | | Elasticsearch | 5K–20K docs/s per node | Indexing, not query |

CAP Theorem — and Why PACELC Is the One You Actually Need

Every engineer knows CAP. Most use it wrong. Here's the practical version that actually helps you in interviews.

CAP theorem: In the presence of a network partition, a distributed system must choose between:

• Consistency (C): Every read returns the most recent write or an error
• Availability (A): Every request returns a response (possibly stale)

Partition tolerance (P) is non-negotiable in any real distributed system. So the real choice is always CP vs AP.

| Choose CP when | Choose AP when | |---|---| | Financial transactions, inventory counts | Social feeds, activity streams | | Medical records, audit logs | User profiles (eventual write propagation acceptable) | | Distributed locks | Shopping carts (merge conflicts resolvable) | | Strong ordering required | High-write, scale-out, < 100ms writes required |

CP examples: PostgreSQL, Spanner, etcd, ZooKeeper AP examples: Cassandra, DynamoDB, CouchDB, DNS

PACELC: the model senior engineers actually use

CAP only applies during a partition — an event that happens maybe 0.1% of the time. PACELC captures the trade-off that's always present:

• If Partition: choose Availability or Consistency (same as CAP)
• Else (normal operation): choose Latency or Consistency

Every time you set replication_factor=3, min_insync_replicas=2 in Kafka, you're making an ELC choice: you accept slightly higher write latency to get stronger consistency. Every time you use async replication, you're trading consistency for latency.

| Database | PACELC classification | What it means | |---|---|---| | Cassandra | PA/EL | Prefers availability in partitions, low latency in normal operation | | Spanner | PC/EC | Prefers consistency always — at the cost of latency (~5–10ms TrueTime) | | DynamoDB | PA/EL (default) / PC/EC (strong reads) | Configurable per request | | PostgreSQL | PC/EC | Strong consistency, synchronous replication | | Redis Cluster | PA/EL | Availability and speed, can lose recent writes on failover |

Consistency Models: The Spectrum

Strong consistency and eventual consistency are the extremes. Production systems usually land somewhere in between. Know these cold.

| Model | Guarantee | When to use | Example | |---|---|---|---| | Linearizability (Strong) | Every op appears instantaneous; reads always see latest write | Financial ledgers, distributed locks, leaderboard counts | Spanner, etcd | | Sequential | All processes see ops in the same order, not necessarily real-time | Coordination services | ZooKeeper | | Causal | Causally related ops seen in order; concurrent ops can diverge | Collaborative docs, distributed counters | CRDTs | | Read-your-writes | A user always sees their own writes immediately | User profiles, comment post-then-display | Primary-reads-after-write | | Monotonic reads | A user never sees older data after seeing newer | Progress tracking, pagination | Sticky sessions to replica | | Eventual | Given no new writes, all replicas converge eventually | Social feeds, caches, analytics | Cassandra, DynamoDB |

In interviews: state the consistency model before the database, not after. "This is a payment service — I need linearizability — so Postgres or Spanner. Not Cassandra."

Database Selection: The Decision Matrix

The most common interview mistake is picking a database because it's fashionable rather than because the access pattern demands it.

| Use case | Best choice | Why | Avoid | |---|---|---|---| | Financial ledger / payments | PostgreSQL | ACID, strong consistency, mature | DynamoDB default (eventual) | | User profiles + joins | PostgreSQL / MySQL | Relational, good for joins, ACID | Cassandra (no joins) | | High-write, horizontal scale | Cassandra / DynamoDB | Tunable consistency, 99.99% uptime, wide column | Postgres (vertical only) | | Session / rate limiting | Redis | Sub-ms, TTL, atomic ops (INCR+EXPIRE) | Postgres (too slow for this) | | Product / content search | Elasticsearch | Inverted index, faceting, relevance ranking | SQL LIKE (no relevance) | | Real-time geo queries | Redis Geo / PostGIS | Native geo commands, S2 / Geohash | App-side filtering | | Event streaming | Kafka | Durable, replay, fan-out, ordered by partition | RabbitMQ (no replay) | | Time-series metrics | InfluxDB / TimescaleDB | Columnar, time-partitioned, downsampling | MySQL (no time ops) | | Large files / media | S3 / GCS | Object store, CDN-ready, cheap | Postgres (blobs kill performance) | | Graph (social network) | Neo4j / Neptune | Native graph traversal | SQL JOINs at N-deep | | Leaderboards / rankings | Redis ZSET | O(log N) sorted set, range queries | Postgres ORDER BY at scale |

Quick decision tree for interviews:

Needs ACID + complex queries?          → SQL (PostgreSQL)
Needs horizontal write scale?          → Cassandra / DynamoDB
Needs sub-ms + TTL + atomic?           → Redis
Needs full-text search + ranking?      → Elasticsearch
Needs files / media?                   → S3 + CDN
Needs time-series + aggregations?      → TimescaleDB / InfluxDB
Needs graph traversal?                 → Neo4j

If you find yourself considering whether to split across two of these, you probably should. Real systems at Swiggy, Razorpay, and Coupang typically use 3–5 storage systems serving different access patterns from a single user journey. Keep this section of the cheat sheet visible when you're mid-interview and the interviewer asks "which database?"

Database Sharding: Strategies and the Hotspot Trap

Sharding is the move you make when a single database node can't handle your write volume or dataset size. The wrong shard key choice is one of the most expensive architectural mistakes to undo.

The three sharding strategies:

Hash sharding — shard = hash(key) % N

• Even data distribution, spreads writes across all nodes
• Range queries hit every shard (expensive)
• Adding a shard remaps ~50% of keys (migration cost is enormous)
• Use for: user data, session data, anything where range queries don't matter

Range sharding — partition by value range (e.g., user IDs 0–1M on shard 1, 1M–2M on shard 2)

• Range queries stay on one shard (fast)
• Monotonically increasing keys (timestamps, auto-increment IDs) create write hotspots — the last shard gets all new writes
• Use for: time-series data where recent data is always the hotspot anyway, and you partition by time window

Consistent hashing — keys and nodes placed on a virtual ring; each key routes to the next node clockwise

• Adding or removing a node only moves ~1/N of keys, not all of them
• Virtual nodes (vnodes): each physical node owns 150–250 virtual positions on the ring for even distribution
• Used by Cassandra, DynamoDB, and Amazon's original Dynamo
• The right default for any new horizontally-scaled system

Hotspot mitigation: When a single entity drives disproportionate load (a celebrity account, a viral product), add a suffix to the shard key: user_id + "_" + random(0,10). Fan out writes to 10 shards, aggregate on reads. Instagram uses this for posts from accounts with 100M+ followers.

Caching Patterns: Which One to Use When

Caching is the fastest way to improve read performance. It's also the fastest way to serve stale data and confuse users. The pattern choice matters.

Cache-Aside (Lazy Loading) — most common in production

Read:  check cache → hit → return | miss → query DB → write to cache → return
Write: write to DB only (invalidate or let expire)

Best for: read-heavy workloads with infrequent writes. Spotify's browse queries, product catalog reads. Risk: thundering herd on cache miss. Mitigate with mutex/lock-on-miss or probabilistic early refresh.

Write-Through — cache updated synchronously on every write

Write: update cache + update DB (both before returning to caller)

Best for: data that's read immediately after write (user profile, cart contents). Risk: write latency doubles. Unused data wastes cache space.

Write-Behind (Write-Back) — cache updated immediately, DB write is async

Write: update cache → queue DB write → acknowledge caller → flush queue to DB

Best for: extremely write-heavy, can tolerate brief data-loss risk. Redis as a buffer before Postgres. Risk: cache failure before flush = data loss. Requires durable queue (not just in-memory).

Cache eviction policies:

| Policy | When to use | Production example | |---|---|---| | LRU (Least Recently Used) | Default for most systems | Redis default | | LFU (Least Frequently Used) | Hot-key detection, CDN edge | Cloudflare edge cache | | TTL-based | When freshness > access pattern | Session tokens, OTP codes | | Random | Very uniform access patterns | Rarely used in practice |

Cache sizing formula:

Cache size = hot data fraction × total working set
80/20 rule: 20% of objects get 80% of reads
Target: store the hot 20% → achieve ~80% hit rate

For a system with 10M active records at 1 KB each = 10 GB working set → 2 GB Redis cache gets you to 80% hit rate. This is the number you give when asked "how big is your cache?"

Load Balancing: L4 vs L7 and the Algorithms

Choosing the wrong layer for your load balancer is a favourite interview trap. Here's the full reference.

L4 (Transport Layer) vs L7 (Application Layer):

| Dimension | L4 Load Balancer | L7 Load Balancer | |---|---|---| | Operates on | IP + TCP/UDP headers only | Full HTTP request (URL, headers, cookies, body) | | Routing capability | IP/port routing only | URL-based, cookie-based, header-based routing | | Throughput | Millions of connections/s per box | Lower — must parse and decrypt every request | | Added latency | Near-zero (<0.1 ms) | 1–5 ms (TLS termination + parsing) | | SSL termination | No | Yes (terminates TLS, forwards HTTP internally) | | Session affinity | IP-hash only | Cookie-based (any user, any IP) | | Use case | Edge, DDoS protection, TCP gaming | API gateway, microservices routing, A/B testing | | Examples | AWS NLB, HAProxy in TCP mode | AWS ALB, Nginx, Envoy |

In production, large systems run both: a stateless L4 tier at the edge (handles millions of connections cheaply), feeding an L7 tier (makes application-aware routing decisions per request).

Load balancing algorithms:

| Algorithm | How it works | Best for | |---|---|---| | Round Robin | Distribute requests sequentially | Identical stateless servers | | Weighted Round Robin | Distribute proportionally to weight | Heterogeneous instance types | | Least Connections | Route to server with fewest active connections | Long-lived connections, variable request duration | | Least Response Time | Route to fastest responding server | Latency-sensitive, dynamic server pools | | IP Hash | Hash source IP → same server always | Stateful apps before you fix them to be stateless | | Consistent Hashing | Hash request attribute to ring → stable routing | Cache affinity, session-less stickiness |

API Design: REST, gRPC, GraphQL — When to Use Which

The wrong API style doesn't cause outages — it causes the wrong kind of pain at scale. Know the decision criteria, not just the definitions.

| Criterion | REST | gRPC | GraphQL | |---|---|---|---| | Protocol | HTTP/1.1 or HTTP/2, JSON | HTTP/2, Protocol Buffers | HTTP/1.1 or HTTP/2, JSON | | Payload size | Verbose (JSON) | Compact (binary, ~5–10× smaller) | Variable (client-specified) | | Schema enforcement | Optional (OpenAPI) | Mandatory (Protobuf IDL) | Mandatory (SDL) | | Streaming | Limited (SSE, chunked) | Native bidirectional streaming | Subscriptions | | Browser support | Native | Requires grpc-web proxy | Native | | Type safety | Optional | Compile-time enforced | Compile-time enforced | | Caching | HTTP cache headers work natively | No HTTP caching | Caching is hard (POST queries) | | Learning curve | Low | Medium | High |

The practical decision rules:

• Use REST for any public API or any interface a browser calls directly. Simple, universal, cacheable. Default choice unless you have a specific reason to deviate.
• Use gRPC for service-to-service communication inside your own infrastructure. You control both sides. Binary protobuf is 5–10× smaller than JSON, streaming is native, and the strict schema prevents the "API drift" that kills microservice velocity.
• Use GraphQL when multiple client types (mobile, web, dashboard) need radically different data shapes from the same backend, and you want to avoid versioning hell and over-fetching. Shopify, GitHub, and Swiggy's super-app use GraphQL at the API gateway to serve mobile and web with different data contracts.

Most mature product companies end up with REST + gRPC. REST at the public edge; gRPC on internal service-to-service calls. GraphQL is added when mobile under-fetching becomes a measurable problem, not as a default. This is the answer to give in any system design cheat sheet question about API style — pick the simplest option that meets your requirements.

Message Queues: When to Use a Queue and Which One

Use a queue when any of these are true:

• The downstream system is slow, bursty, or unreliable
• You need at-least-once processing guarantees with retry
• Processing can happen asynchronously (outside the user-facing request)
• Multiple consumers need the same event (fan-out)
• You need to decouple write spikes from downstream capacity

Use a direct call when:

• The caller needs the response synchronously to proceed
• The downstream is always-fast and always-available
• There's exactly one consumer and no retry requirement
• Simplicity > resilience for this specific operation

Queue selection reference:

| Queue | Best for | Key properties | Avoid when | |---|---|---|---| | Kafka | High-throughput event streams, audit log, analytics | Durable, replayable, ordered within partition, 1M+ msg/s | You need per-message ACK and simple task queues | | RabbitMQ | Task queues, per-message acknowledgment, routing logic | Lower throughput, rich routing (exchanges), per-message ACK | You need replay or long retention | | AWS SQS | AWS-native, managed, at-least-once, simple | Fully managed, dead-letter queues, FIFO option | You need ordering or sub-second latency | | Redis Pub/Sub | Fire-and-forget fan-out, ephemeral notifications | Sub-ms, no persistence, at-most-once | You cannot tolerate message loss | | Redis Streams | Persistent log with consumer groups | Persistent, replayable, consumer groups, lightweight Kafka | You need Kafka-grade throughput or cross-region replication |

Rate Limiting: Algorithms and Implementation

Every public API needs rate limiting. Every interview that touches API design will ask about it.

The four algorithms:

| Algorithm | How it works | Pros | Cons | |---|---|---|---| | Token Bucket | Bucket fills at fixed rate; each request consumes a token | Handles burst traffic gracefully | Allows 2× burst at boundary | | Leaky Bucket | Requests drain at fixed rate; overflow is dropped | Smooth output rate | Drops burst traffic, bad for bursty-legit users | | Fixed Window | Count requests per fixed time window (e.g., per minute) | Simple to implement | Boundary burst: 200 requests in 2 seconds straddling a minute boundary | | Sliding Window Log | Track exact timestamps of each request | Precise | Memory-heavy at scale |

Production implementation with Redis:

# Token bucket in Redis — atomic with Lua script
BUCKET_KEY = f"rate:{user_id}"
LIMIT = 100          # tokens per window
WINDOW = 60          # seconds
REFILL_RATE = 100    # tokens per window

current = redis.incr(BUCKET_KEY)
if current == 1:
    redis.expire(BUCKET_KEY, WINDOW)
if current > LIMIT:
    raise RateLimitExceeded(f"Limit {LIMIT} req/{WINDOW}s exceeded")

Multi-tier rate limiting (what production systems actually do):

1. L7 load balancer level — coarse limit, protects against DDoS (10K req/s per IP)
2. API gateway level — per-API-key or per-user-ID limit (100 req/min for free tier)
3. Service level — per-resource limit to protect downstream (50 DB writes/s per tenant)

Coupang's payment API uses three independent rate limit tiers to prevent a single tenant's write spike from degrading the DB for all other tenants.

30 Design Decisions in One Minute Each

The interview is 45 minutes. You'll make 15–20 design decisions in that time. Know these cold.

| Question | The answer (state this, then justify if probed) | |---|---| | Unique IDs at scale? | Snowflake ID (64-bit, sortable, distributed, no DB round-trip) or UUID v4 (simpler, not sortable) | | Shard a database? | Hash shard on entity ID for even distribution; range shard on time for time-series | | Prevent double charge? | Idempotency key (UUID from client) + DB unique constraint (server dedup) | | Rate limit an API? | Token bucket in Redis (INCR + EXPIRE per user_id key) | | Deduplicate messages? | Dedup window in Redis (SETNX + TTL on message_id, check before processing) | | Fan-out at scale? | Kafka with multiple consumer groups — one event, multiple independent consumers | | Invalidate a cache? | TTL-based expiry + event-driven invalidation on write (belt and suspenders) | | Celebrities in social graph? | Hybrid fanout: push to followers for normal users, pull for accounts > 1M followers | | Route to nearest server? | GeoDNS (DNS-level) + anycast routing (same IP, nearest PoP) | | Handle slow downstream? | Circuit breaker (Hystrix pattern) + fallback response | | Batch high-volume writes? | Buffer in Redis, flush every 100ms or 1000 items to DB | | Full-text search? | Elasticsearch (inverted index, BM25 scoring, faceting) | | Store large files? | S3 + CloudFront CDN; store reference URL in DB, never the blob | | Generate short URLs? | Base62-encode a counter (not hash — hash has collisions); Bloom filter for uniqueness check | | Track user presence? | Heartbeat every 30s from client → Redis key with 60s TTL; expired = offline | | Geofencing? | Geohash for radius queries; S2 cells (Google H3) for polygon containment | | Hot key in cache? | Local in-process cache on app server (30s TTL) + read replicas + key sharding | | Distributed locking? | Redis SETNX + TTL for single-node; Redlock algorithm for multi-node HA | | Sync across services? | Saga pattern — choreography (event-driven) for < 5 steps, orchestration for > 5 | | Roll back a payment? | Compensating transaction — reverse the charge in a new idempotent operation | | Version an API? | /v1/, /v2/ prefix — versioning in the URL, not in headers (headers are invisible to proxies) | | Protect a public API? | Rate limiting + JWT auth + input validation (Zod / Joi / Protobuf) | | Thundering herd on cache? | Jitter on TTL (TTL + random(0, 10%)) + mutex-on-miss + probabilistic early refresh | | Monitor a service? | USE model: Utilization, Saturation, Errors. Track p50/p99 latency, error rate, queue depth | | Reduce read latency path? | CDN → Redis → read replica → primary (waterfall, stop at first hit) | | Async background jobs? | Queue → idempotent worker with retry + dead-letter queue for failures | | Handle large payloads? | Multipart S3 upload; store object reference in request, never inline payload | | Bootstrap a cold cache? | Pre-warm on deploy using top-N most-read keys; use read-through on misses | | DB migration safely? | Expand-contract: add new column backward-compatible → deploy → backfill → drop old | | Measure cache effectiveness? | hit_rate = hits / (hits + misses). Target > 80%. Below 60% = wrong data in cache. |

The 45-Minute Interview Structure

All the knowledge above is useless if you can't deploy it in the right order under time pressure.

Minute 0–5: Requirements

• Functional: "What are the core operations? Create/read/update/delete? Real-time or async?"
• Non-functional: "What's the scale target? Latency requirement? Consistency requirement? Durability?"
• Scope: "Should I include auth, monitoring, billing? Or focus on the core data path?"

Minute 5–10: Estimation (use the formulas from the top of this post)

• DAU → QPS (read + write separately)
• Storage per year
• Bandwidth (peak write + read)
• Number of servers

Minute 10–20: High-Level Design

• Draw the request path from user to data — client → LB → app servers → cache → DB
• Name components (Nginx, Redis, Postgres) — not "a load balancer"
• State your consistency model before your database choice

Minute 20–35: Deep Dive (pick 2–3 critical components)

• The interviewer will direct you — respond to their probe
• Show trade-offs: "I could use X or Y — X wins here because [specific reason]"
• Handle the hardest requirements: hot keys, write spikes, data loss scenarios

Minute 35–40: Bottlenecks and Trade-offs

• "The first bottleneck is the DB write path — here's how I'd shard it"
• "The consistency model I chose means [this trade-off] — acceptable because [reason]"

Minute 40–45: Wrap-up

• Monitoring: what would you alert on? (p99 latency, error rate, queue depth)
• What would you build first vs in v2?
• What did you consciously not design and why?

Reliability Patterns: The Four You Must Know

Circuit Breaker — prevents cascade failures

Closed → count failures → threshold exceeded → Open (fail fast, no requests)
Open → after timeout → Half-Open (trial request) → success → Closed

Use when: calling external services (payment gateways, third-party APIs) that can go slow or fail. Implementations: Hystrix (Netflix), Resilience4j, Envoy sidecar.

Bulkhead — isolate failure domains by resource partitioning Separate thread pools for critical vs non-critical operations. If your notification service thread pool saturates, it doesn't starve your payment service threads. Used by: every major microservices platform. Uber uses bulkheads to ensure Surge Pricing service failures don't impact Ride Dispatch.

Retry with exponential backoff + jitter

wait = min(base_delay * 2^attempt + random(0, base_delay), max_delay)
# base_delay=100ms, max_delay=30s, 5 attempts
# attempts: 100ms, 200–400ms, 400–800ms, 800–1600ms, 30s

Always add jitter. Synchronized retries from 1,000 clients amplify the failure instead of relieving it.

Idempotency — safe to retry without side effects Every write operation that can fail should have an idempotency key:

CREATE TABLE payments (
  idempotency_key VARCHAR(64) UNIQUE,  -- client-supplied UUID
  status          VARCHAR(20),
  amount          NUMERIC(12,2),
  ...
);
-- Second INSERT with same key hits the UNIQUE constraint, returns existing row

The unique constraint in the DB is your final guard. The application layer checks first; the DB enforces it absolutely.

Turn This Into Working Knowledge

This cheat sheet covers the frameworks. What it can't do is prepare you for the follow-up questions — the "why did you choose Cassandra over Postgres here?" and "what happens if this cache node fails mid-request?" moments that separate candidates who've thought through systems from those who've memorised diagrams.

The system design practice track on KnowEase covers 15+ HLD problems with structured frameworks, AI-graded answers, and targeted follow-up scenarios designed specifically for SDE2–Staff interviews at product companies. Each problem is scored on the same rubric interviewers actually use.

For the back-of-envelope framework in more depth, the HLD interview framework guide breaks down the 45-minute structure with worked examples.

One thing changes how fast this system design cheat sheet becomes instinct: doing timed practice with real feedback, not reading notes. The engineers who walk into system design interviews confident aren't the ones who read the most — they're the ones who practiced until the decision trees were automatic. Come back to this reference when your estimation numbers feel uncertain, or when you're second-guessing a consistency model choice.