System Design Practice
Any model can hand you a written answer to “design a URL shortener.” None of them can make you say it out loud, under time pressure, and defend the trade-off when someone pushes back. That's what these drills are for.
The drills
Every question carries the meta you actually want before you start: how often it comes up, which companies ask it, what kind of question it is, and how long you get.
30 questions· showing 1–10
01Rate Limiter for a Public API
Full drill“We expose a public API and some clients are hammering it. Design a rate limiter for us.”
02URL Shortener
Full drill“Design a URL shortener — something like TinyURL or bit.ly.”
03Social News Feed
Full drill“Design the home timeline for a social app — the feed a user sees when they open it.”
04Chat / Messaging System
Full drill“Design a messaging app like WhatsApp. Start with one-to-one chat and we'll go from there.”
05Ticket Booking Without Double-Booking
Full drill“Design seat booking for something like BookMyShow or IRCTC. Two people tap the same seat at the same moment — what happens?”
06Notification Service
Full drill“We need to send notifications — push, SMS, and email — across the company. Design that service.”
07Ride Hailing — Matching Riders to Drivers
Full drill“Design the part of Uber or Ola that matches a rider to a nearby driver.”
08SQL or NoSQL — Defend the Choice
Full drill“You picked that database. Why not the other one? Talk me through when you'd switch.”
09Consistency vs Availability, In Practice
Full drill“You said the system is eventually consistent. What does that actually mean for a user, and when would you not accept it?”
10p99 Latency Spiked at 2am
Full drill“You're on call. p99 latency on the checkout API just went from 200ms to 4 seconds. Error rate is flat. Walk me through what you do.”
The rest are listed because they come up constantly — their full drills are being written. You can still attempt any of them; the guides linked on each cover the ground.
How the drills work
Same mechanic as the DSA track: the answer stays locked until you've made your own attempt.
The question, as asked
Phrased the way an interviewer says it out loud — vague on purpose, so you have to scope it yourself.
You answer first
Commit your approach before anything unlocks. The forced attempt is the point — reading a model answer teaches you far less than failing to produce one.
Three depths of model answer
The 30-second version you actually say, the 10-minute whiteboard version that passes the round, and the deep dive for when they push.
The follow-ups
What the interviewer asks next, and the trade-offs you need a defensible opinion on.
The material underneath
Every drill links into this. Work it in whatever order the question sends you — roadmap for the sequence, guides for the depth, simulators for the intuition you can't get from prose.
Play with the trade-offs
Sharpening your coding rounds in the meantime? Head to DSA practice.