Posts

“Book a train ticket” sounds like inserting a row. Then you look at Tatkal. At 10:00:00 sharp, a few days’ worth of demand for a scarce quota lands in a single second. Two or three million people press “Book” against a train that has maybe eighty Tatkal seats. The seats sell out in ten to twenty seconds. Every one of those millions must get a truthful answer - a confirmed seat with a berth number, a waitlist position, or a clean rejection - and no seat may ever be sold twice, because a double-booked berth is two paying passengers standing in the same coach at midnight. This is not a CRUD service with a form in front. It is a scarce-inventory contention problem where the read load is enormous, the write load is fierce and concentrated, and correctness on the write path is absolute. ...

“Design MakeMyTrip” sounds like a shopping app: a user types two cities and a date, a list of flights comes back, they pick one and pay. The interviewer lets that run for a minute, then asks the question the toy version cannot answer. A user in Bangalore types “BLR to DEL, 12 August, 1 adult” and expects, in under two seconds, a ranked list of every way to make that trip - direct flights and connections - across 50-plus airlines, each with a real bookable price, layover, and total duration. MakeMyTrip does not own a single seat. The inventory lives behind dozens of airline APIs and Global Distribution Systems, each slow, rate-limited, priced per query, and disagreeing about what a fare costs from one second to the next. ...

You retired last month with ₹40 lakh you want to keep safe and income-producing. Every relative has an opinion: “SCSS, 8.2%, government-backed, done.” Someone else swears by the RBI Floating Rate Bond. Your banker is quietly pushing a senior-citizen FD. The lazy answer is “put it all in SCSS, it pays the most.” You cannot. SCSS caps a single account at ₹30 lakh. So the real question is not “which one” but “what do I do with the ₹10 lakh that will not fit in SCSS, and does the tax on all of it change the ranking?” ...

“Let users log in” is the request that hides an entire distributed system. You need to store a password without ever storing the password, verify it in a way that is slow for attackers but fast enough at 100K logins a second, hand out a credential the user carries around, revoke that credential the instant an account is compromised, survive a leaked database dump, layer on a second factor, and let people sign in with Google without you ever seeing their Google password. Every one of those is a place the system breaks, and most of them are places where breaking means a breach, not a slow page. ...

Facebook Marketplace looks like “Craigslist with photos,” and if you design it that way you will fail the interview. The naive read is a CRUD app: a listings table, a search box, a chat window. But every one of those three has a scale trap hiding in it. The listing store is easy until you remember that “500M active listings” means half a billion rows that are constantly created, edited, marked sold, and expired, each with several photos that dwarf the metadata. The search box is easy until you realize the query is not “find listings matching iphone” but “find listings matching iphone, priced under 30000, in category Electronics, within 10km of where I am standing, sorted by relevance and recency” - a keyword search and a geospatial search and a set of filters, all at once, over 500M documents, at ~150k queries a second. And the chat window is easy until you count the fraud: Marketplace is one of the most heavily-abused surfaces on the internet, so a scammer posting a fake listing and a stolen-goods reshipping scheme are not edge cases, they are the main event. ...

“Show live prices for every stock on every exchange to millions of people at once” reads like a websocket that pushes a number. Then you look at what is actually flowing. Global exchanges emit millions of price ticks per second across hundreds of thousands of symbols. You have millions of users connected, each watching a different handful of symbols, each expecting the number to move within a blink of it moving on the exchange floor. The problem is not “get a price,” it is fan-out: one tick for a hot symbol must reach potentially a million users’ screens in under 100ms, and you cannot afford to send every tick to every user or run a query per user per tick. ...

Most salaried Indians treat their family as a single taxpayer. It does not have to be. If you are Hindu, Jain, Sikh, or Buddhist, the law already recognises a second, separate assessee living in your house: the Hindu Undivided Family. It gets its own PAN, its own Rs 2.5 lakh basic exemption in the old regime (Rs 4 lakh in the new one), and its own full Rs 1.5 lakh 80C limit. Route the right income into it and you are splitting that income across two tax brackets instead of piling it all onto one. ...

The most dangerous line of code in a microservice is not the one that crashes. It is this one: order = db.save(order) # write to Postgres kafka.publish("orders", order) # tell the world It looks correct. It passes every test you write. It works in staging for months. Then one Tuesday your billing service is missing 0.3% of orders, nobody can explain it, and the audit takes three days because there is no error anywhere. The database has the order. Kafka does not. No exception was thrown. No alert fired. The two systems just quietly disagreed, and you found out because a customer did not get charged. ...

“Monitor the health of the cluster” sounds like a cron job that pings every box and pages someone when one goes quiet. Then you put 50,000 nodes behind it and ask for sub-second detection, and every easy choice breaks. Poll 50K nodes from one monitor and you cannot finish a sweep in a second. Trust a single missed heartbeat and every GC pause or 200ms network blip pages you at 3am. Auto-restart on the first miss and a flaky switch takes down a rack, then your remediation logic restarts all of it in a storm and you have turned a blip into an outage. The whole problem is doing three hard things at once: detect a real failure in under a second across 50K nodes, be sure it is real and not a false alarm, and act on it without making things worse. ...

Everyone thinks PagerDuty is a glorified SMS sender. “A monitoring tool posts an alert, you look up who is on call, and you text them. If they do not reply, you text the next person.” Then the interviewer starts asking the questions that turn it into a real system: how do you know who is on call right now when the schedule is a weekly rotation with a holiday override layered on top and the engineer is in a different timezone? When you say “escalate if not acknowledged within 5 minutes,” where does that 5-minute timer live so that it still fires if the machine holding it crashes? If the same outage trips 400 alerts in ten seconds, how do you page one human once instead of 400 times? And the thing that actually matters: the entire product is a promise that when production breaks at 3am, exactly one awake human gets woken up and, if they do not answer, the timer does not silently die - it escalates. A dropped page is the one bug this system is not allowed to have. ...

The whole point of a file-transfer service sounds like a solved problem: put the file on a server, hand out a URL, let people download. That works until the file is 10GB and a million people want it in the same hour. Now do the arithmetic the interviewer is waiting for: 10GB times 1,000,000 downloads is 10 petabytes of egress, and if half of them show up in the first hour you need roughly 10 PB / 3600s ≈ 2.9 TB/sec of outbound bandwidth from your origin. No single origin, no CDN tier you would willingly pay for, serves 2.9 TB/sec for one file. The server-centric model does not scale sub-linearly with popularity - it scales linearly, and popularity is exactly when it collapses. ...

Every few months someone declares RAG dead. The argument is always the same: context windows keep growing, so just stuff the whole corpus into the prompt and let the model sort it out. No chunking, no embeddings, no vector database, no retrieval logic. Delete half your pipeline. I have built both. I have shipped a system that dumped 150K tokens of documentation into every request, and I have shipped chunked retrieval over the same corpus. The long-context version was simpler to build and worse to run. It was slower, it cost roughly 30x more per query, and on a specific class of questions it was measurably less accurate. ...

Two people open a PPF account on the same day, put in the same ₹1.5 lakh every year for 15 years, and earn the same 7.1% rate. One ends up with roughly ₹2.7 lakh more than the other. Neither picked a better fund, took more risk, or timed the market. One just deposited early in the financial year and the other deposited late. That is the entire difference, and it comes down to a rule most PPF holders have never actually read. ...

One engineer using Claude Code is a productivity story. Ten engineers using Claude Code on the same repo, with no shared conventions, is a coordination problem that looks a lot like the early days of untyped JavaScript on a big team. Everyone is fast individually. Collectively you get inconsistent code, a CLAUDE.md that three people edit in three directions, and a PR queue full of 800-line diffs that the author skimmed and nobody else wants to read. ...

Tapping “Like” is the smallest interaction Facebook has. It is one bit: you either like a post or you do not. It looks like a toggle on a boolean. It is not. Behind that single tap sits a counter that must be accurate (a user liking twice counts once, an unlike must decrement, the number cannot drift over a billion taps), durable (unlike a live viewer count, a like is a real fact the user expects to persist forever), and live (the number should tick up on every viewer’s screen as others tap, without a refresh). And then there is the part that actually breaks systems: a celebrity or a viral post can take 100,000 likes per second, all landing on the count of a single post. One row. One key. A firehose. ...

Live comments look like a solved problem until you put a number on it. A celebrity goes live, a million people are watching, and comments are pouring in at ten thousand a second. Every one of those million viewers is supposed to see new comments appear the instant they are posted. Do the multiplication and the system dies on the spot: 10,000 comments/sec times 1,000,000 viewers is 10 billion messages per second if you naively push every comment to every viewer. No fleet on earth moves 10 billion messages a second for a single post. ...

“23 people are looking at this hotel right now.” It is one line of text, a soft nudge that the room might not be here tomorrow. It looks trivial. It is not. To render that number you have to answer, for every one of a million product pages, a question that is genuinely hard at scale: how many distinct humans are looking at this page right now, updated live, refreshed as people arrive and leave, across a global fleet. ...

The usual advice for a girl child’s corpus is a one-liner: “equity always beats a government scheme over 21 years, so run an SIP.” It sounds obviously true. Nifty has done roughly 11-12 percent over long stretches, and Sukanya Samriddhi Yojana pays 8.2 percent. Case closed. Except that 8.2 percent is tax-free and guaranteed, and your mutual fund is neither. Once you put both through the tax code and hold them for the same 21 years, the bar the fund actually has to clear is not “beat 8.2 percent.” It is higher than that, and where it lands depends on one thing most comparisons never mention: which tax regime you are in. Let me compute the exact break-even CAGR, to the rupee. ...

A wire transfer looks like the wallet transfer’s twin, and interviewers love it because it is not. In a wallet, “move 500 from Alice to Bob” is one UPDATE inside one ACID transaction because both accounts live in your database. A wire moves money between two different banks. The debit lives in your ledger; the credit lives in a bank you cannot see, reach transactionally, or roll back. There is no shared transaction. There is an external rail (Fedwire, RTGS, SWIFT, ACH) that is slow, at-least-once, and - once it settles - irreversible. You cannot ROLLBACK a wire. You can only send a second, compensating wire and hope. ...

One request hits your API gateway, which calls auth, which calls the user service, which calls three downstream services, two of which hit a cache and a database, one of which enqueues a job that a worker picks up 40ms later. That single user-facing click fanned out into 30 service calls across 12 machines, and it was slow - 1.2 seconds when it should be 200ms. Which hop ate the second? Logs won’t tell you: they are 30 disconnected lines in 12 different files with no thread that ties them together. Metrics won’t tell you: they say “p99 latency is up” but not which call in which request. The thing that ties them together - the single most valuable artifact in a microservice debugging session - is the trace: the full call tree of one request, every span timed and parented, so you can see exactly where the 1.2 seconds went. ...