Interviews

“Stream processing” sounds like a for loop over a queue: read a message, do a thing, write a result. That mental model dies the moment the thing you do has memory. Count events per user per minute, and now you have state - which user is at what count, and what happens to that count when the machine holding it dies mid-minute? Read late-arriving events, and now “per minute” is a lie, because messages do not arrive in the order they happened. Ask for exactly-once, and now a crash between “read”, “update the count”, and “write the result” cannot be allowed to double-count or drop, across three different systems at once. A durable log that just moves bytes is the easy half. The hard half is running stateful computation over that log at a million messages a second per topic without losing, duplicating, or mis-ordering a single result when a node inevitably falls over. ...

Everyone thinks top-K is a SELECT article_id, COUNT(*) FROM shares GROUP BY article_id ORDER BY count DESC LIMIT 100. Store every share, group, sort, take the top 100, done. Then the interviewer adds the constraints that make it a real problem: it is not one all-time ranking, it is three sliding windows at once - the top 100 in the last 5 minutes, the last hour, and the last 24 hours; there are 100 million articles; there are a billion shares a day, spiking hard when something goes viral; and the answer has to be near-real-time, so a share that just happened should be able to move an article onto the list within a second or two, not on the next hourly batch. ...

“Nearby Friends” looks like the Uber problem wearing a different hat - a map, some dots, find the ones near me. It is not. Uber asks “out of 5 million strangers moving around, who is the single nearest one,” and answers it with a spatial nearest-neighbour index. Nearby Friends asks a different and in some ways nastier question: “out of my friends specifically, which ones are within 5km of me right now, and keep that answer live as both of us walk around.” The set you care about is not “everyone near this point” - it is the intersection of two things that both change every few seconds: the social graph (who is my friend, who opted in) and live geography (who is physically close). The hard part is the fan-out: when I move, which friends need to be told, and when a friend moves, do I need to know? Do that naively for 50M concurrently-moving people each with hundreds of friends and you generate billions of pointless distance checks a second. ...

Everyone underestimates log aggregation because the demo is trivial: run an agent on a box, ship each line over the network, dump it into a searchable store, done. Then the interviewer sets the actual scale - 100,000 servers, ~10M events per second, retain 30 days, query it all from a dashboard - and every part of the trivial version dies. Ten million events a second is roughly 3 GB/sec on the wire and hundreds of terabytes a day; a single server’s agent hiccuping cannot be allowed to drop your incident forensics; the read pattern is a schizophrenic mix of “aggregate this numeric metric over a range” and “grep for this rare error string across a petabyte in the last 30 days”; and the naive fix - “just index every word so search is fast” - is precisely the decision that makes your index bigger than your data and bankrupts the cluster. ...

Pastebin looks like a URL shortener with a bigger payload, and people design it that way: mint a key, stuff the text somewhere, return a link. Then the interviewer pushes. Where does the actual paste body live - in the database? What happens to your row size and your backups when someone pastes a 5MB stack trace? How do you serve a billion reads a day when each response is not a 500-byte redirect but a 10KB blob? How do 100 million pastes expire without a cron job melting the database? Now it is a real system. ...

“Match buy and sell orders” sounds like a database join. Then you look at the constraints. A million orders a second arrive from thousands of members. Two orders for the same stock at the same price must fill in the exact order they arrived - not roughly, exactly - because that ordering is money and it is legally auditable. The same stream of orders replayed on a backup machine must produce byte-for-byte the same trades, or your failover invents fills that never happened. A single mismatched fill is a broken trade, a regulatory incident, and a lawsuit. This is not a CRUD service with a queue in front. It is a deterministic state machine that happens to be one of the most latency-sensitive pieces of software people build. ...

“Design Airbnb” sounds like a listings app: a host posts a room, a guest searches a city, they book, money changes hands. The interviewer lets that run for a minute, then asks the two questions the toy version cannot answer. First: a guest in Bangalore types “Goa, 24-27 December, 2 guests” and expects, in under a second, the handful of places that are actually free for those exact three nights out of millions of listings. Second: two guests, on two continents, both tap “book” on the same beach villa for overlapping dates at the same instant. Exactly one of them can win, and the loser must never receive a confirmation for a villa that is already taken. ...

Instagram sounds like Twitter with pictures, and half of it is. The follow graph, the feed of people you follow, the celebrity who breaks fan-out - all of that is the same problem the news feed poses, and I will not pretend otherwise. But the other half is the part people wave away in interviews and then drown in: a photo is not 280 bytes of text, it is a 3MB blob that has to be uploaded over a flaky phone connection, resized into five renditions, stored durably forever, and then served from an edge cache to millions of people in under 100ms. At 100M uploads a day that media pipeline is its own distributed system, and it is where this design actually gets hard. ...

The recommendation engine is the product. Netflix does not have a search box you visit with intent; it has a home screen that must guess, before you type anything, which of ~100,000 titles you want to watch tonight - and it must guess differently for you than for the 200M other people staring at their own home screens. Get it wrong and the user scrolls for four minutes, gives up, and cancels next month. The naive framing (“show popular stuff”) dies immediately: popularity is the same for everyone, and the whole point is that it must not be. The real problem is this: for every one of 200M users, score a catalog of ~100,000 titles against everything we know about that user, return the top few dozen ranked for their taste in under ~100ms, and shift those recommendations within seconds of them finishing an episode - without re-scoring 100,000 titles per user per request, and without waiting hours for a nightly batch job to notice they just binged a new genre. ...

Everyone thinks a job scheduler is a while loop with a sleep. “Check the clock, if a job is due run it, sleep a second, repeat - cron already does this, it is fifty lines.” That mental model survives exactly until the interviewer asks the questions that turn it into a real system: you run three copies of the scheduler for availability, so when a job comes due, does it fire once or three times? The scheduler process was down for ten minutes during a deploy - the 2am backup job never fired, is it gone forever or does it run late? A job takes an hour and the worker running it crashes at minute 55 - does anyone notice, and does it restart from scratch or double-charge the customer? You have ten million jobs due at midnight because everyone set their cron to 0 0 * * * - does the whole system fall over at the top of the hour? ...

“Design Swiggy” looks like a restaurant catalogue with a Buy button. Browse restaurants, tap dishes into a cart, pay, wait for food. The interviewer lets that picture stand until they ask the question that breaks it: a single order is a contract between three independent parties who do not trust each other and are never all online at once - a customer who has already paid, a restaurant that has to accept and cook, and a delivery partner who has to be found, sent to the restaurant, and routed to the door. None of them is under your control. The restaurant can reject. The partner can cancel at the pickup. The customer can change the address mid-cook. And the whole thing has a hard 40-minute deadline before the food is cold and the order is a refund. ...

“Design Google Maps” sounds like it is about drawing a map. It is not. The map tiles are the easy, cacheable part. The interviewer is really asking two hard questions stacked on top of each other. First: there are hundreds of millions of places on Earth - restaurants, petrol pumps, ATMs, chemists - and a user standing on a street corner types “coffee” and wants the ten nearest open cafes, sorted, in under a second. How do you find “things near this point” out of a planet’s worth of static points without scanning the whole globe? Second: that same user then taps one of those cafes and asks for directions, and you have to compute the fastest route across a road graph with hundreds of millions of edges, weighted by live traffic, in a few hundred milliseconds. How do you plan a shortest path across a continent without running Dijkstra over the entire road network on every request? ...

Almost every large system needs one boring-sounding thing: a way to mint unique identifiers. Tweet IDs, order IDs, message IDs, row keys. It sounds trivial until you write down the real constraints: the IDs must be unique across thousands of machines, they must be generated at hundreds of thousands per second, no single box is allowed to be a bottleneck or a point of failure, and (the part people miss) they should be roughly sortable by creation time so you can use them as primary keys and range-scan recent data. ...

A key-value store looks like a solved problem for about thirty seconds. “Put a value under a key, get it back later, it is a hash map.” Then the interviewer says: it has to survive a machine catching fire, it has to stay writable when the network splits the cluster in half, it has to hold petabytes across thousands of nodes, and two clients are going to write the same key at the same instant from two different data centers. Now every easy answer is wrong. Which node owns a key when nodes are constantly joining and leaving? If you replicate a write to three nodes and one is down, do you fail the write or accept it? When two writes race, which one wins, and how do you even know they raced? And can the caller ask for “fast and maybe stale” on one request and “slow and correct” on the next? ...

Everyone thinks a monitoring system is a database with a graph on top. “Every server writes its CPU and memory somewhere, you draw a line chart, and you send an email when the line goes red.” Then the interviewer adds the constraints that turn it into a real system: it is not a hundred servers, it is millions of time series reporting every few seconds; the same metric name with a slightly different label becomes a brand-new series, so a careless user_id label can explode your storage a thousandfold overnight; a query for “p99 latency across the fleet for the last 30 days” must not scan a trillion raw points; and an alert that fires two minutes late during an outage is worse than useless because the pager is how you find out production is down. ...

Everyone thinks a message queue is a list. “Producers push messages onto the back, consumers pop them off the front, done - it is a queue, the name is right there.” That mental model survives exactly until the interviewer asks the questions that make it a real system: what happens when the consumer crashes halfway through a batch, does the message come back or is it gone? What happens when you have a thousand consumers and one queue, how do they share the load without stepping on each other? What happens when the broker holding your messages dies, are the messages gone with it? And when the network retries a publish, does the message land once or twice, and who pays for the duplicate? ...

A video platform looks trivial for about five seconds: POST /video to upload, GET /video to play. Then you remember that one uploaded file is a 4GB 4K master that has to become a dozen different renditions, that a viewer on a train switching between 5G and a tunnel needs the stream to drop from 1080p to 240p without stalling, that the actual bytes are served to billions of people from machines physically close to them and never from your origin, and that the view counter under the video is being incremented tens of thousands of times per second on the popular ones. The upload button is the easy 1%. The real system is this: turn one giant immutable master file into many small streamable segments, store those segments once and serve them from the edge, let the player pick the right quality moment to moment, and count views and watch time at a scale where a naive UPDATE ... SET views = views + 1 would fall over on day one. ...

Everyone thinks a leaderboard is a SELECT ... ORDER BY score DESC LIMIT 100. “Store the scores, sort them, return the top 100, done.” Then the interviewer adds the real constraints: it is not just the top 100, a player who ranks 4,192,304th wants to see their own rank and the ten people around them; scores update constantly as millions of people play, and a single kill or a single point can move someone up thousands of positions; the board must feel live, so a score bump should show up in a second, not on the next nightly batch; and there is not one board, there is a global all-time board, plus a daily board, a weekly board, and one per region, all at once. ...

Everyone starts a web crawler the same way: a queue of URLs, a while loop, fetch, parse out the links, push them back on the queue, repeat. It works on ten pages. Then the interviewer turns it into the real problem: crawl the whole web - billions of pages - politely (never hammer one server), without downloading the same page twice, without getting stuck in an infinite maze of dynamically generated URLs, across hundreds of machines, and refresh it all continuously because the web changes under you. ...

Everyone thinks an ad click aggregator is a SELECT COUNT(*) ... GROUP BY ad_id. “Log every click, count the rows, show the advertiser their numbers, done.” Then the interviewer adds the constraints that make it a real system: it is not a thousand clicks, it is millions of clicks per second at peak; advertisers pay per click so a double-counted or dropped click is literally money moving the wrong way; the dashboard must feel live, so a click should show up in seconds, not in tomorrow’s batch; and the same numbers must also be provably correct at the end of the day for billing, even though clicks arrive late, out of order, and sometimes twice. ...