Posts

“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. ...

Most SGB articles you will read are a forecast: buy this, hold eight years, and here is a hypothetical CAGR. That era is over. The first big tranches issued in 2018 have now hit their eight-year maturity, so we can stop guessing and read the receipt. This post takes one specific bond that matured a couple of months ago, works out to the rupee what a holder actually walked away with, and lines it up against a gold ETF and physical gold bought on the very same day. ...

Here is the assertion that breaks every engineer coming to LLM apps from normal software: assert output == expected is useless. You cannot write it. The same prompt, the same model, the same temperature, and you still get two different strings on two runs. Even at temperature zero you get drift across model versions, across providers routing you to a different GPU, across a retried request. The equality check that anchors all of regular testing is gone. ...

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. ...

Most people put their emergency fund in a savings account and never think about it again. That single default, held for years on a fund that might run to four, five, six lakh, quietly costs more than any expense-ratio debate people love to have about their equity SIPs. A savings account paying 2.75% against a liquid fund near 6.75% is a gap of roughly 4% a year on money that is supposed to be a boring safety net. ...

If you have watched a demo where an AI agent “modernizes” a codebase in one shot, you have watched a toy. Point the same agent at a real system - 200,000 lines of PHP 5 with no tests, three generations of ORM, and business logic smuggled inside stored procedures - and it will produce confident garbage. It will rename things, break the build in ways the build does not report, and quietly change behavior that nobody wrote down anywhere. ...

“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. ...

The default advice is “buy the biggest base health cover you can afford.” It is also the most expensive way to reach a high sum insured. If your goal is Rs. 25 lakh of protection for your family, buying it as one Rs. 25 lakh base policy can cost you 30-40% more every year than building the same Rs. 25 lakh out of a modest base plus a super top-up. ...

Most teams treat the system prompt as a text field. Someone pastes a paragraph into a string literal, the demo works, and it ships. Then three weeks later a support engineer tweaks one sentence to fix a single bad conversation, redeploys, and the app quietly starts returning malformed JSON for 4% of requests. Nobody notices for a day because there is no test that would catch it. That is what a system prompt actually is: the highest-leverage, least-governed piece of code in your entire application. ...

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? ...

Streaming looks solved. You flip stream=True, loop over deltas, append text to a div, and the demo feels magical. Then it ships, and the bug reports start. The response cuts off halfway on flaky mobile connections. The JSON you were parsing mid-stream throws because you got half a key. A tool call fires but your renderer already committed to showing text. A user hits stop and the backend keeps burning tokens for another thirty seconds. ...

“I will start next year, once my salary jumps and the car loan is done.” It sounds responsible. Delay a five-year plan by five years and you have lost one-sixth of it, so surely the damage is one-sixth, about 17%. It is not. A five-year delay on a 30-year SIP runway does not cost you 17% of your corpus. It costs you roughly 46% of it. On a ₹10,000/month SIP aimed at retirement, that gap is about ₹1.61 crore of wealth that simply never gets created. ...

Search “MCP server” and you get a thousand guides that all stop at the same place: paste this JSON into your Claude config, restart, done. That is installation. Nobody writes the other half - how to actually author a server, wire it to a real backend, protect it with auth, and ship it so other people can install it. This post is that half. I have shipped a couple of internal MCP servers over the last few months. The protocol is simple, but the gap between “works in Claude Desktop on my laptop” and “a thing other engineers can trust” is wide, and it is mostly made of the parts the tutorials skip. So we will build a real server end to end: a task tracker that reads projects, runs tools, authenticates callers, and publishes to the registry. ...

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. ...