Case studies
Fourteen design problems in practice order, with what each interviewer tests and the components your answer must contain.
This page is a practice schedule, not an answer key. Each entry tells you what the interviewer is testing and which components must appear on your whiteboard. Draw the design yourself, then compare it against the building blocks.
Why there are no solutions here
Reading a solution feels like learning and is not. You need the blank page, the 45 minutes, and the moment you run out of things to say. Do that first, every time.
The weekly cadence
Two case studies a week from week 22. Weeks 21 and 23 are lighter because the project work is heavier there.
Ten minutes on requirements. Write the users, the core actions, the read and write ratio, and the scale numbers. Ask the interviewer two questions out loud.
Thirty minutes drawing. Boxes, arrows, and one sentence per box. Do not erase. Note every assumption in the margin.
Five minutes on tradeoffs. Name the bottleneck, the single point of failure, and what you would do differently at ten times the load.
The next day, redraw the same design from memory in ten minutes. If you cannot, you did not learn it.
Keep a log of the week, the design, and the one thing you missed. That log is your revision list in May.
SDE-1 core, weeks 21 to 27
Payments ledger (week 21)
They test whether you can move money without losing or duplicating it. Your answer needs an append-only ledger with double-entry rows, an idempotency key on every write, a transactional outbox, and a nightly reconciliation job. Level: SDE-1 must. This is Ledgerline in interview form.
Ecommerce product listing (week 22)
They test read-heavy design and cache freshness. You need a product service in front of Postgres, a cache for product pages, a search index that handles filters and sort order, and a write path that invalidates or versions cache entries. Level: SDE-1 must. Say what happens when a price changes mid-session.
API rate limiter (week 22)
They test shared state under concurrency. Show a token bucket stored in Redis, one atomic check-and-decrement operation, a rule for the Redis-down case, and where the limiter sits (gateway or service). Level: SDE-1 must. Name the algorithm before you draw anything.
Notifications at scale (week 23)
They test fan-out and failure handling. Your answer needs a queue per channel, a preference store that decides who gets what, a worker pool with retries and a dead-letter queue, and idempotency so a retry does not send twice. Level: SDE-1 must. Push, email and SMS fail differently, so say so.
URL shortener (week 24)
They test whether you can keep a simple thing simple. Expect a key generation scheme, a read path of one lookup plus a cache, a redirect status chosen for a reason, and analytics written off the hot path. Level: SDE-1 must. Do not over-build it.
GitHub Gists and PasteBin (week 25)
They test storage choices and access rules. You need object storage for blobs, Postgres for metadata and ownership, a cache for hot pastes, and a decision on when syntax highlighting runs (write time, not read time). Level: SDE-1 must. Draw the read path for an anonymous paste.
Metrics and observability pipeline (week 25)
They test volume and retention thinking. Your answer needs agents that scrape and push, a time-series store with downsampling, a query layer, and alert rules evaluated away from the write path. Level: SDE-1 must. The dashboards in Shiplane are your working version.
Chat or presence system (week 26)
They test long-lived connections. Show WebSocket gateways with sticky routing, a presence store kept alive by heartbeats, a fan-out path for users who are offline, and an ordering rule per conversation. Level: SDE-1 must. Presence is the part candidates skip.
Realtime abuse detection (week 27)
They test streaming aggregation under a latency budget. You need an event stream from signup and login, sliding-window counters per IP and per account, a rules layer that blocks or challenges, and a feedback loop for false positives. Level: SDE-1 nice. Attempt it only if weeks 22 to 26 went well.
Depth designs, weeks 28 to 32
These four are SDE-2 material. Do them after the offer, or in the last two weeks if your loops are going well. They are marked in the plan as later work for a reason.
Tinder-style feed (week 28)
They test geospatial queries and ranking. Your answer needs a location index (geohash or PostGIS), a candidate query with filters for age, distance and already-seen profiles, a ranking score, and a swipe store that prevents repeats. Level: SDE-2 later. Explain how you avoid showing one profile twice.
Twitter trends (week 29)
They test heavy-hitter counting. Show the firehose ingestion path, windowed counting with an approximate structure (count-min sketch or sampled counters), a spike detector that handles a burst, and a cache serving the trend list. Level: SDE-2 later. Exact counts are not the point; the pipeline is.
Fraud detection (week 30)
They test whether you separate scoring from deciding. You need a feature store, a scoring call inside a tight latency budget, rules or a model behind it, and an audit log of every decision. Level: SDE-2 later. Say how a false block gets reversed.
Recommendation engine (week 31)
They test the offline and online halves. Expect batch jobs that build embeddings or item similarities, a feature store, an online ranker, and an evaluation loop with an offline metric plus a live test. Level: SDE-2 later. Your retrieval work gives you the vocabulary; use it.
Web crawler (week 32)
They test politeness and scale. Your answer needs a URL frontier with priority, fetchers that respect robots.txt and per-host rate limits, a dedupe store for seen URLs, and a parse and store step. Level: SDE-2 later. Dedupe is where most answers fall apart.
Common mistakes
- Ask two clarifying questions before drawing anything.
- State the read and write ratio, even if you have to estimate it.
- Draw the data model. Interviewers notice when it is missing.
- Say "I would start simpler because" and then say why.
- Write your assumptions in the margin and keep them visible.