System Design — Top Questions at MAANG (2026)
On this page
- 1. Classic top 12 (still asked every cycle)
- 2. 2026 NEW: GenAI / LLM-infra designs (HIGH PRIORITY for you)
- 3. Healthcare-domain SD (warm rounds at HealthTech)
- 4. The 6-step framework (use this religiously in every SD interview)
- 5. Numbers you MUST have memorized (back-of-envelope)
- 6. Trade-off cheatsheet (memorize the words)
- 7. Practice schedule
- Sources
At L4/SDE-II/E4 the bar is: complete reqs → high-level → 1 deep-dive on a subsystem → discuss trade-offs. You have 45–60 min. 2026 shift: ~50% of SD loops now include an ML/GenAI-adjacent design (was ~10% in 2024). You already have real LLM rate-limiter and EHR-summarization experience — leverage it.
1. Classic top 12 (still asked every cycle)
| # | Design | Key concepts | Most-asked at |
|---|---|---|---|
| 1 | URL Shortener (TinyURL / Bitly) | Base62 encoding, KGS (key gen service), cache, sharding by hash, 301 vs 302 | Amazon, Apple |
| 2 | News Feed (Twitter / Instagram) | Push vs pull vs hybrid, fan-out, ranking, timeline cache, hot users problem | Meta ★★★ |
| 3 | WhatsApp / Messenger | Long-poll vs WebSocket vs MQTT, end-to-end encryption, online presence, group fan-out, message ordering | Meta, Amazon |
| 4 | Uber / Lyft (ride-matching) | Geo-hashing, S2/H3, driver location stream, matching service, surge pricing | Google, Amazon |
| 5 | YouTube / Netflix (video) | Transcoding pipeline (you’ve built one!), CDN, ABR streaming (HLS/DASH), recommendation engine | Netflix ★★★, Amazon |
| 6 | Google Drive / Dropbox | Chunking, dedup, sync algorithm, conflict resolution, metadata service | Google, Amazon |
| 7 | Search engine / autocomplete | Inverted index, trie+heap for autocomplete, prefix freq, sharded index | Google ★★★, Amazon |
| 8 | Distributed cache (Redis cluster) | Consistent hashing, replication (sync/async), eviction (LRU/LFU), hot key problem, cache stampede | Amazon, Meta |
| 9 | Rate limiter | Fixed window / sliding window / token bucket / leaky bucket, Redis-based vs in-memory, distributed sync | Amazon ★★, Stripe |
| 10 | Notification system | Multi-channel (push/SMS/email), priority queue, retry with backoff, dedup, fan-out | Amazon |
| 11 | Web crawler | BFS frontier, politeness (robots.txt + per-host rate limit), URL dedup (bloom filter), distributed workers | |
| 12 | Online code editor (Leetcode/Coderpad) | Sandboxed containers, persistent storage of submissions, real-time collab (OT/CRDT) | Coderpad, Meta |
2. 2026 NEW: GenAI / LLM-infra designs (HIGH PRIORITY for you)
These now appear in ~50% of senior loops. You have direct production experience — frame your Jio work in interview language.
| # | Design | Frame using your Jio work | Companies asking |
|---|---|---|---|
| 13 | LLM API serving (think: design ChatGPT API backend) | Your AI Rate Limiter + LLM Orchestration | OpenAI, Anthropic, Google, Meta, AWS Bedrock teams |
| 14 | RAG system | Vector DB (Pinecone / pgvector / Weaviate), embedding pipeline, hybrid retrieval, re-ranking, prompt cache | Cohere, Glean, every AI startup |
| 15 | Multi-tenant LLM cost optimizer / rate limiter | This IS your project — write it up as gold-standard answer | Amazon, Anthropic, Meta AI infra |
| 16 | Real-time clinical AI summarization | Your Clinical AI Summarization Engine — FHIR ingest → batching → LLM → cache → guardrails | Verily, Tempus, Hippocratic AI, Anthropic Health |
| 17 | AI agent backend (Claude-Code / Cursor style) | Tool-calling protocol, sandboxed exec, conversation memory, streaming, observability | Anthropic, OpenAI, Cursor |
| 18 | Vector search at scale | Approx NN (HNSW, IVF, ScaNN), sharding, hybrid index, freshness | Pinecone, Meta, Google |
| 19 | Feature store for ML | Online + offline parity, point-in-time correctness, registries | Tecton, Uber, Netflix |
Interviewer ask in 2026: “How would you design serving infra for an LLM API that handles thousands of concurrent requests with variable latencies?” — answer with your AI Rate Limiter as the concrete example you’d build on.
3. Healthcare-domain SD (warm rounds at HealthTech)
Use these at Verily / Oscar / Tempus / Cigna-Evernorth / Hippocratic AI / Aetna / Walmart Health.
- Design HIPAA-compliant EHR data sync (CDC + Kafka + Postgres — your CDC microservice)
- Design FHIR resource server (RESTful, eventual consistency, paging, $search, OAuth/SMART-on-FHIR)
- Design e-Prescribing system (idempotency, audit, NCPDP integration)
- Design real-time medical-alerts pipeline (vitals stream → ML scoring → on-call notification)
- Design patient-reported outcomes (ePRO) collection at scale — you’ve shipped this
4. The 6-step framework (use this religiously in every SD interview)
1. Clarify (2–5 min) Functional + non-functional reqs, scale, read/write ratio, latency target
2. API (3 min) REST/gRPC signatures, key entities
3. Data model (3 min) Tables/collections, indices, partition keys
4. High-level (10 min) Boxes & arrows: client → LB → service → cache → DB + async (Kafka)
5. Deep-dive (15 min) ONE component the interviewer picks (or you pick the spiciest)
6. Trade-offs (5 min) CAP, sync vs async, SQL vs NoSQL, push vs pull, monolith vs MS
Buffer 5 min for questions. Practice the boxes-and-arrows in 10 min rule — it’s the #1 reason candidates fail.
5. Numbers you MUST have memorized (back-of-envelope)
| Op | Latency |
|---|---|
| L1 cache | 0.5 ns |
| L2 | 7 ns |
| Main memory | 100 ns |
| SSD random read | 150 µs |
| Round-trip same DC | 0.5 ms |
| Round-trip cross-region | 100–150 ms |
| HDD seek | 10 ms |
| Read 1 MB from memory | 250 µs |
| Read 1 MB from SSD | 1 ms |
| Read 1 MB from network | 10 ms |
| Read 1 MB from HDD | 30 ms |
QPS / storage approximations:
- 1 day = 86 400 sec ≈ 10⁵
- 1 million writes/day ≈ 12 writes/sec, with peak ×3 = 36 writes/sec
- 1 user post avg 500 bytes; 1 B users × 1 post/day = 500 GB/day
- Single MySQL box: ~5–10 K reads/sec, ~1–2 K writes/sec
- Single Redis box: ~100 K ops/sec
- 1 Kafka partition: ~10 MB/s, ~1 K msg/s sustainable
6. Trade-off cheatsheet (memorize the words)
- CAP: pick 2. Cassandra/Dynamo = AP. HBase/MongoDB-default = CP. PACELC is the better mental model.
- SQL vs NoSQL: SQL → ACID, joins, complex queries. NoSQL → horizontal scale, schema flex.
- Push vs Pull (feed): push = fast read, write amp. Pull = light write, slow read. Hybrid for celebrities.
- Sync vs async replication: sync = strong consistency + write latency; async = eventual + risk of data loss.
- Caching strategies: cache-aside (Redis next to DB), write-through, write-back, write-around.
- Idempotency: client-supplied request ID + dedup table — talk about this in any write API.
- Backpressure: explicit token bucket > implicit thread pool exhaustion.
7. Practice schedule
| Week | Designs |
|---|---|
| 10 | TinyURL, Twitter, WhatsApp |
| 11 | Uber, YouTube/Netflix, Instagram |
| 12 | Google Drive, Distributed cache, Rate limiter |
| 13 | LLM serving, RAG, Cursor-backend (GenAI focus) |
| 14 | FHIR server, EHR sync, ePRO pipeline (healthcare) |
For each: write a single markdown file in this folder with:
- Functional + non-functional reqs
- API
- Data model
- Diagram (ASCII or describe)
- 1 deep-dive
- 3 trade-offs you’d flag