Posts

“Notify me when AAPL hits $250” or “tell me when this Amazon item drops below Rs 1,999” sounds like a WHERE price >= target query. Then you look at the numbers. There are 100M active alerts. Stock prices update millions of times a second across tens of thousands of instruments. If you run that WHERE on every price tick you are doing millions of full scans per second over a hundred million rows, and you melt. The whole problem is the inversion: it is not “given a price, which alerts match” as a database scan, it is “given a firehose of price changes, fire exactly the alerts that just got crossed, once, within a second, without scanning anything you do not have to.” ...

Most people think ESOPs are taxed when they cash out. They are not. They are taxed twice, on two different dates, at two completely different rates, and the two are decided by two different rules you do not get to choose after the fact. The day you exercise, you owe income tax at your salary slab rate on a gain you have not seen in cash. The day you sell, you owe capital gains tax on whatever the stock did after that. Miss the connection between those two dates by one day, and on a stock that has run up you can hand the government an extra 10-15% of the whole vested value for nothing. ...

The single most expensive career mistake I see senior engineers make is treating the management track as a promotion. It is not a promotion. It is a lateral move into a different job that happens to pay similarly at the same level. The confusion is structural. Most companies draw the ladder so that “senior engineer” branches into two lines that sit at the same level: engineering manager on one side, staff engineer on the other. Both get a title bump. Both get a comp bump. So it looks like a fork with two equally good roads. It is not two versions of your current job. It is two different jobs, and the skills that made you a great senior engineer transfer cleanly to only one of them. ...

An A/B testing platform is deceptively easy to describe and brutal to get right. “Show half the users the blue button and half the green button, then see which converts better.” Every part of that sentence hides a landmine. Which half - and does a returning user stay in the same half tomorrow, or does the button flicker between visits? What happens when there are not two experiments but three thousand running at once, some of them overlapping on the same page? How do you count 500M users worth of impressions and conversions per experiment without a nightly batch job that reports yesterday’s winner today? And the one that sinks most naive designs: how do you decide the green button actually won, versus won by random noise, without a statistician manually eyeballing a spreadsheet? The real problem is this: assign 500M users to variants across thousands of concurrent experiments deterministically and with sub-millisecond latency on the request path, capture a firehose of exposure and conversion events without losing any, and compute per-experiment statistical significance in near-real-time - all while guaranteeing that a user never flips variants mid-experiment and that overlapping experiments do not silently poison each other’s results. ...

Once a rider is matched to a driver, the interesting problem is not “who is my driver” - it is the little car crawling across the map toward the pin, and the number under it that says “4 min” and keeps updating. Both look trivial. Both hide the hard part. The car moving smoothly is the output of a fan-out system that takes one driver’s GPS ping and delivers it to the exact rider watching that trip, in under a second, five million times over. The “4 min” is the output of a routing engine that has to answer “how long from here to there, given the traffic right now” continuously for the entire duration of every trip, without recomputing a shortest path over a road graph on every single ping. ...

Everyone thinks the screen limit is a counter. “Each plan allows N streams, keep an integer per account, increment when a play starts, decrement when it stops, reject when it hits N. Done.” Then the interviewer asks the questions that decide whether it actually works: what happens when the player crashes and never sends the decrement, so the counter leaks upward until a paying family can never watch anything again; what happens when two devices in the same house both hit play in the same 50 milliseconds on the last free slot; how do you make that allow/deny decision fast enough that nobody notices it before their video starts; and how do you do all of it for 250 million subscribers with 100 million concurrent streams at peak. Now it is a real problem. ...

Here is a fact that trips up almost everyone parking money in a tax-saver FD: your fixed deposit and an NSC certificate bought on the same day, in the same 30 percent bracket, are taxed exactly the same way. Every rupee of interest is added to your income and taxed at slab. So the “safe FD” argument is not about tax. It is purely about the headline rate. And on that single number, the NSC at 7.7 percent beats a 6.5 percent tax-saver FD every single time, before you even open a calculator. ...

Almost every article on this topic stops at the arithmetic: book Rs 1.25 lakh of gain a year, save 12.5% tax on it, do it fifteen times instead of once. That math is real and it is settled. What nobody writes about is the part where people actually lose money: the execution. I have watched people “harvest” and end up worse off than if they had done nothing. They redeemed on a day the NAV had already run up, they tripped the holding-period reset and paid short-term tax at 20%, they had already used the exemption on a stock sale they forgot about, or they harvested an ELSS unit that was still locked. The exemption is free. Getting the mechanics wrong is not. ...

The whole problem is one sentence: the data does not fit in memory. You have 1TB to sort and 16GB of RAM per machine, so the data is roughly 64x larger than the memory you get to sort it in. Every classic in-memory sort - quicksort, the sort() in your standard library - assumes random access to the entire array. The moment the array is bigger than RAM, that assumption is gone, and the algorithm either crashes with an out-of-memory error or thrashes the page cache into oblivion. So the real question is not “which comparison sort,” it is “how do you order data you can only ever see a small window of at a time.” The answer, since the 1960s, is external merge sort: read data in chunks small enough to sort in memory, write each sorted chunk to disk, then merge the sorted chunks back together with a streaming k-way merge that only ever holds one small buffer per chunk in RAM. Scale that across a cluster and you get the distributed sort that wins the TeraSort benchmark. This post builds both, single machine first because the distributed version is just external sort with the partitioning done up front. ...

Surge pricing looks like a multiplication. Base fare times some number, show it to the rider, done. The interviewer lets that sit for about a minute, then asks the questions that break the toy: the number is different on this block than the next one over, it changes every 30 seconds, there are a million of these blocks worldwide all updating at once, a rider who sees 1.8x must be charged 1.8x even if the number moves while they are tapping “confirm,” a driver deciding whether to drive to the airport needs the surge there to still be real when they arrive 12 minutes later, and if you get the number wrong in either direction you either strand riders or enrage them. Surge is not a multiplication. It is a real-time distributed control loop over supply and demand, and the price is just its output. ...

Everyone thinks App Store rankings are a SELECT app_id, COUNT(*) FROM downloads GROUP BY app_id ORDER BY count DESC LIMIT 100. Count the downloads, sort, take the top 100, done. Then you look at a real store and the assumption falls apart in three separate ways at once. First, “trending” is not the same as “most downloaded” - a five-year-old app with a huge install base racks up more downloads per minute than a brand-new hit, yet the new hit is what is trending, so trending has to measure velocity, not volume. Second, there is not one chart, there is a chart per country times per category times per window (top free, top paid, top grossing), which is tens of thousands of distinct top-K lists that all have to stay fresh. Third, the windows are not all the same shape - “top 100 trending every minute” is a fast rolling score, “top 1000 daily” and “weekly” are rolling windows that must expire old events, and “top 1000 all-time” is a monotonic cumulative counter that must never forget anything. One naive GROUP BY cannot be all three. ...

The most common piece of tax advice for equity investors in India is “just buy and hold, don’t churn, LTCG is only 12.5% anyway.” It is not wrong. But it quietly throws away a benefit the tax code hands you for free every single year: the Rs 1.25 lakh long-term capital gains exemption. If you never sell until the end, you claim that exemption exactly once. If you book gains deliberately every April and buy the units straight back, you claim it fifteen times over a fifteen-year holding. Nothing about your portfolio changes. You hold the same fund, the same NAV, the same units. You just reset your cost basis higher each year and walk away from a tax bill you would otherwise pay at the finish line. ...

Ask most engineers to build a rate limiter and you get the same answer: INCR a Redis key, set a 60 second TTL, reject when the count crosses the limit. It ships, it passes the demo, and it is wrong in a way that will not show up until a real client with real burst behavior hits it in production. That INCR counter is a fixed window, and a fixed window has a specific, exploitable failure mode that lets a client send double its limit in a two second span. ...

Since April 2023, the standard advice has flattened into a shrug: “debt funds and FDs are taxed the same now, so just pick whatever.” That is lazy and it is costing 30% bracket investors real money. Yes, the headline tax rate is identical. FD interest, debt fund gains and corporate bond fund gains are all taxed at your income slab in 2026. But identical tax rate does not mean identical post-tax return. The gap comes from when the tax is charged, the gross yield you start with, and what you give up in liquidity. For a 3-5 year parking of ₹10 lakh, that gap is worth roughly ₹30,000-35,000. Not life-changing, but not nothing, and it is free. ...

There are two completely different things people call “a message queue,” and confusing them is the fastest way to fail this interview. One is a log - Kafka-shaped, an append-only tape where the broker is dumb, never deletes on read, and every consumer tracks its own position. The other is a broker - RabbitMQ-shaped, a smart mailbox where the broker owns each message, hands it to exactly one consumer, waits for an acknowledgment, and redelivers if that ack never comes. This post builds the second one, because the requirements name it: at-least-once delivery, priority queues, dead-letter queues. Those are broker features. A log does not track per-message delivery state, cannot prioritize one message over another sitting behind it, and has no notion of “this message was rejected three times, send it somewhere else.” A smart broker does. ...

Everyone thinks Google Analytics is a counter with a chart on top. “Drop a snippet on every page, count the pageviews, draw a line graph, done.” Then the interviewer piles on the constraints that make it a real system: it is not one website, it is billions of them, each a separate tenant that must only ever see its own data; it is not a thousand hits, it is 100 billion events a day landing from every corner of the internet; the product does not show one number, it shows a live “users on site right now” ticker and “sessions per day for the last 18 months” and “of everyone who saw the product page, what fraction added to cart then checked out” and “of the users who first showed up in March, how many came back in April.” Those are four completely different query shapes over the same firehose, and one of them (unique users) cannot even be answered exactly at this scale without melting. ...

“Design Google Calendar” sounds like a CRUD app: a user creates an event, it shows up in a grid, the phone syncs it. The interviewer lets that run for a minute, then asks the four questions the toy version cannot answer. First: a user creates “team standup, every weekday at 9am, forever” - do you really write one row per day until the heat death of the universe? Second: someone opens the scheduling assistant, picks eight coworkers across four timezones, and expects to see everyone’s free-busy for next Tuesday in under a second. Third: a billion users have reminders set, and each must fire within a few seconds of its due time even though “due time” depends on the attendee’s timezone and DST rules. Fourth: I edit an event on my laptop offline on a plane, my phone edits the same event, and both must converge without losing data when I land. ...

Most “zero-downtime deployment” tutorials show you two identical stacks, a load balancer, and a switch you flip from blue to green. Traffic moves, nobody notices, everyone claps. That demo works because the demo has no database, no long-lived connections, and no in-flight work. Every hard part of a real deployment is exactly the part the demo removed. The honest version: swapping stateless web servers is a solved problem. The moment your deploy also changes a database schema, drops a websocket, or invalidates a session, “zero downtime” becomes a set of design constraints on your application code, not a checkbox on your CI pipeline. This post walks the naive blue-green picture, breaks it on purpose, and maps each failure mode to a pattern that actually handles it. ...

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