System Design Interview Cheat Sheet

System design interviews look chaotic, but they're not. After 50+ interviews on both sides of the table (and reviewing what Portify's hiring partners actually ask), the same 5 architectural patterns appear in 80% of senior interview loops.

If you can confidently sketch all five with their trade-offs, you're ready for most senior interviews. This is that cheat sheet.

The interview structure (always the same)

1. Clarify requirements (5 min) — functional, non-functional, scale
2. High-level design (10 min) — boxes and arrows
3. Deep dive on one component (20 min) — interviewer's choice
4. Scale + bottleneck discussion (15 min) — the "what if 10x more users"
5. Wrap-up (5 min) — what would you do differently with more time

Beginners skip step 1 and dive into boxes. Always start with clarifying questions. The interviewer has scoped the problem; ask what's in / out.

Pattern 1 — Read-heavy services (e.g., Twitter feed, news, search)

When reads >> writes (like 1000:1):

• Cache aggressively — Redis or Memcached in front of the database
• Read replicas — primary takes writes, replicas serve reads
• CDN for static + semi-static assets
• Denormalize — pre-compute the data shape the read needs

Trade-off: cache invalidation is the hard part. The classic line: "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."

When pressed: how do you invalidate? Two strategies:

• TTL (time-to-live) — simple, works for most cases, accept some staleness
• Write-through invalidation — write to DB + cache simultaneously, harder to get right but stays fresh

Pattern 2 — Write-heavy services (e.g., logging, analytics, IoT)

When writes >> reads:

• Append-only data structures — never UPDATE, only INSERT
• Sharding by key — split writes across N databases by user_id, region, time, etc.
• Asynchronous queue between client and storage — Kafka, RabbitMQ, SQS
• Time-series databases if applicable — InfluxDB, TimescaleDB

Trade-off: queries on this data are slow because you're optimized for writes. Acceptable for analytics (run once per hour); not acceptable for "show me my recent activity".

Pattern 3 — Real-time / stateful services (e.g., chat, collaborative docs, live games)

When users need updates without polling:

• WebSockets — the canonical answer. Persistent connection per user.
• Server-sent events — simpler if you only need server → client (e.g., notifications)
• Pub/sub at the back — Redis pub/sub, Kafka, NATS — to fan out messages across server instances

Scaling consideration: sticky sessions. With multiple WebSocket servers, a user's connection lives on ONE server; you need to route their messages back to that server. Solutions: load balancer with sticky sessions, or a pub/sub fabric so any server can route.

Pattern 4 — Job-queue / async processing (e.g., email sending, video transcoding)

When the user request shouldn't wait for the work:

• Producer puts a job on a queue (RabbitMQ, SQS, Redis-backed queue)
• Worker pool consumes — separate process / container fleet, scale independently
• At-least-once delivery is the realistic promise — design jobs to be idempotent
• Dead-letter queue for failed jobs — manual investigation later

Common interview trap: "What happens if the worker crashes mid-job?" The right answer involves idempotency keys, transactions, and a retry policy with exponential backoff.

Pattern 5 — Geographically distributed (e.g., global apps, edge compute)

When latency matters across continents:

• CDN for static — Cloudflare, Vercel Edge, Fastly
• Multi-region database — primary in one region, read replicas in others
• Eventual consistency — accept that the EU read might not show the US write for ~1s
• Geo-DNS / Anycast — route user to the nearest server

Trade-off: writes are still slow because they go back to the primary. Strong consistency across regions is hard (Spanner/CockroachDB exist; they're slower than single-region Postgres).

The 5 questions you should always ask in step 1

1. "What's the daily active user count?" — sets the scale tier
2. "What's the read/write ratio?" — picks the pattern
3. "Are we optimizing for latency or throughput?" — affects every architecture choice
4. "What's the consistency requirement?" — strong, eventual, or "best effort"?
5. "Are there any compliance / data-residency requirements?" — GDPR changes the database story significantly

Numbers every senior developer should know cold

These come up CONSTANTLY in scale discussions:

| Operation | Approx latency | |---|---| | L1 cache reference | 0.5 ns | | L2 cache reference | 7 ns | | RAM reference | 100 ns | | SSD random read | 150 µs | | Network round-trip in same datacenter | 0.5 ms | | HDD seek | 10 ms | | Network round-trip US ↔ Europe | 150 ms |

The point: disk is 1000x slower than RAM. Network across continents is 100,000x slower than RAM. Architectural decisions follow from this.

| Storage | Approx capacity | |---|---| | L1 cache | KB | | L2 cache | MB | | RAM | GB | | SSD | TB | | HDD | TB | | S3 | "infinite" |

What to actually study

If you have 1 week before an interview:

1. Re-read this cheat sheet
2. Watch Hello Interview — free system design walkthroughs
3. Practice ONE end-to-end design (TinyURL, Uber, or a chat app) on a whiteboard, out loud, twice

If you have a month:

1. Read Designing Data-Intensive Applications by Martin Kleppmann — chapters 1-9 cover 80% of what's tested
2. Practice 5 designs out loud, get someone to interrupt you mid-design with "what if 10x more users?"
3. Build ONE distributed system project (even a toy one — sharded key-value store, simple message queue) so you have real experience to draw on

Senior interviews ≠ trick questions

System design interviews aren't IQ tests. The interviewer wants to see how you think under pressure: do you ask clarifying questions, do you make trade-offs explicit, do you know when to choose simplicity over completeness?

The answer "I don't know, but I'd reach for X to figure it out" is often better than a confident wrong answer.

When you're ready to apply, browse senior backend and full-stack roles on Portify. Most include the system you'd be designing in the job description — read it before the interview.