Interviews

“Design BookMyShow” looks like a catalogue app: list cities, list movies, list showtimes, take a payment, print a QR code. The interviewer lets that version breathe for about a minute, then drops the question the toy design cannot answer: a cricket final goes on sale at 10:00 AM, 2 million people hit the same match’s seat map in the same second, and seat H14 in the same stadium can only be sold to exactly one of them. Two people are staring at the same seat, both tap “pay,” both cards are valid. Who gets it, and how do you make sure the other one never gets a confirmation for a seat that is already gone? ...

A file sync service sounds like a glorified upload button until you count the bytes. The naive version is a single PUT /file that stores a blob and a GET /file that returns it - and it works right up to the moment a user edits one paragraph in a 2GB video project and your service happily re-uploads all 2GB over their home DSL line. Multiply that by 700M users across 4 devices each, all expecting a saved file to appear on every other device within seconds, and the upload button collapses. The entire engineering problem of Dropbox is this: move the minimum number of bytes to keep N devices holding identical file trees, while storing those bytes once no matter how many users or versions contain them, and reconciling edits that happen concurrently on devices that were offline and never saw each other. ...

Everyone thinks autocomplete is a LIKE 'prefix%' query. “Index the search terms, run a prefix match, return the top ten, done.” Then the interviewer adds the real constraints: the dropdown must update on every keystroke, so you are firing a query every ~50ms while someone types; it must feel instant, which means the whole round trip - network, lookup, ranking, render - has a budget under 100ms; the corpus is billions of queries and the popular ones shift by the hour; and “top ten” is not alphabetical, it is ranked by popularity, which a prefix index does not give you for free. ...

Everyone thinks a cache is a hash map with a size cap. “Store key-value pairs in RAM, evict when it fills up, done.” Then the interviewer makes it distributed: the data no longer fits on one machine, you have twenty cache nodes, and now the hard questions arrive. Which node owns a given key, and what happens to every other key when you add node twenty-one? How do you decide what to throw out when memory is full, and does that decision cost you a lock on the hot path? When the source-of-truth database changes, how does the stale copy in the cache get corrected without a thundering herd? And when one celebrity key gets ten million reads a second, how do you stop a single node from melting? ...

“Move 500 rupees from Alice to Bob” sounds like an UPDATE statement. Then you think about it. What if the request times out and the client retries - did the first one go through? What if the debit succeeds and the process crashes before the credit? What if two withdrawals from the same wallet run at the same instant and both read the old balance? What if the bank tells you a transfer succeeded but your database says it failed? What if a support agent needs to prove, three years later, exactly where a specific rupee went? The one-line update is actually a distributed system with an idempotency layer, an immutable ledger, a state machine per transaction, an integration with unreliable external banks and gateways, and a reconciliation job that catches the cases where all of that still drifted. ...

A document editor sounds trivial until you put two people in the same document. One editor is a text box that saves to a database: type, PUT /document, done. The interviewer nods, then asks the question that detonates the whole design: what happens when Alice and Bob both type into the same sentence at the same time? Alice inserts “Hello " at position 0 while Bob inserts “World” at position 5, their edits cross in flight over the network, and now each person’s copy of the document has to end up identical to the other’s - even though they applied the same two edits in a different order. Get that wrong and the document silently corrupts: characters land in the wrong place, text duplicates, people lose work. That is unacceptable in a system whose entire promise is “we will never lose your writing.” ...

“Send the user a notification” sounds like one function call. Then you write it down. Which channel - push, email, SMS, in-app? What if the user turned push off but left email on? What if APNs is down for ten minutes? What if the order service retries and now the user gets charged-confirmation SMS three times? What if a bug in one service starts emitting a million notifications a second and you SMS your entire user base at a rupee each? The one-line function is actually a distributed system with a fan-out, a provider integration layer, a retry engine, a preference store, and a rate limiter, and every one of those is a place it breaks. ...

Everyone thinks the rate limiter is a for-loop with a counter. “Count requests per user per minute, reject when it goes over 100, done.” Then the interviewer asks the questions that actually matter: which algorithm, where does the counter live when you have 40 API servers behind a load balancer, how do you stay accurate when two servers increment the same user’s counter at the same millisecond, and how much latency does this add to every single request in the system. Now it is a real problem. ...

“Design Uber” sounds like a CRUD app with a map on top. A rider taps a pin, a driver shows up, money moves. The interviewer lets you believe that for about thirty seconds, then asks the question that breaks the toy version: there are 5 million drivers on the road right now, each one broadcasting its GPS position every few seconds, and a rider standing on a corner wants the nearest available car in under a second. How do you find “the closest driver” out of millions of constantly-moving points, hundreds of thousands of times per second, without scanning the whole planet on every request? ...

Everyone thinks the URL shortener is a trivial problem. “It’s a hash map. Store long URL, return short URL, done.” Then the interviewer asks: how do you generate the key, how do you avoid collisions, what happens when one popular link gets 50,000 redirects a second, and how do you serve that redirect in under 10ms across the globe. Now it’s a real system. The whole problem is deceptively read-heavy and deceptively about one decision: how you mint short keys. Get the key generation wrong and everything downstream (collisions, hot shards, wasted storage) gets worse. Get it right and the rest is caching and sharding you already know. ...

The Twitter timeline looks trivial until you say the numbers out loud. “Show me a list of tweets from people I follow, newest first.” It is a join. SELECT * FROM tweets WHERE author IN (my followees) ORDER BY time DESC LIMIT 50. Done. Then the interviewer points out that some users follow 5,000 accounts, some accounts have 100 million followers, the timeline must load in under 200ms, and 300 million people refresh it all day. The join is now the most expensive query on the internet. ...

A chat app sounds like the easiest system you will ever build. “User A sends a message, user B receives it.” One INSERT, one SELECT. The interviewer lets you say that, then asks the questions that turn it into one of the hardest real-time systems in the building: how does B receive it instantly when B might be offline, on a train, or logged in on three devices at once? How do you show the second grey tick the moment it lands on B’s phone, and the two blue ticks the moment B actually opens the chat? How do hundreds of millions of phones hold an open connection to your servers at the same time without melting? ...

You have 47 browser tabs open. One is a YouTube video on consistent hashing. Another is a blog post about CAP theorem. Somewhere in the mix is a Reddit thread titled “How I cracked system design interviews in 3 months.” You have been studying for two weeks and somehow feel like you know less than when you started. The problem is not a lack of resources. It is the lack of a sequence. System design topics build on each other, and jumping straight to “design Twitter” without understanding database sharding is like trying to build a roof before laying the foundation. ...

You’re in a system design interview. You say “we’ll use PostgreSQL” and immediately follow it with “and we’ll shard it across 16 nodes.” The interviewer asks: “How much traffic are you expecting?” You don’t have a number. You just sharded because it sounded like the senior thing to do. Here’s the thing - most teams shard too early. A single PostgreSQL node can handle far more than people think. The decision to shard should come from actual numbers, not vibes. This post gives you those numbers. ...

You’re building a notification bell. The product team wants it to feel “real-time.” You reach for WebSockets because that’s what every blog post tells you. Six months later, you’re debugging a connection manager that handles reconnections, heartbeats, load balancer stickiness, and auth token refresh - all for a feature where a 5-second delay would have been perfectly fine. The problem isn’t picking the wrong tool. It’s not understanding the tradeoffs before picking. ...

Most candidates jump to drawing boxes on a whiteboard. Here’s the exact structure, order, and time allocation that turns a chaotic 45 minutes into a clear, compelling system design walkthrough.

Most candidates either skip estimation entirely or spend five minutes doing exact math. Here’s how to do quick, high-signal capacity estimation that actually drives architecture.

Saying ’the system should be scalable and highly available’ is not an NFR. Here’s how senior engineers define NFRs that actually drive architecture - with a framework, examples, and checklist.

Most candidates list features. Senior engineers define the system’s contract. Here’s a framework to get FRs right - with examples, anti-patterns, and a checklist.

Your college name is not the blocker you think it is. Here is a honest roadmap from someone who has seen both sides of the interview table.