Posts

“Design Tinder” sounds like Instagram with a nicer gesture. Show a photo, swipe left or right, if two people both swipe right they can chat. The interviewer lets that toy version sit for about a minute, then drops the number that breaks it: 2 billion swipes a day. That is roughly 23,000 writes per second on average and 70,000+ at peak, every single one of them a tiny row that says “user A has an opinion about user B,” and every one of them potentially the second half of a mutual match that has to fire a notification within a second. ...

Most couples put the home loan in one name. Usually the husband’s, sometimes “whoever the bank suggested,” almost always “to keep it simple.” That single decision quietly throws away up to Rs 3.5 lakh of deductions every year, because home loan tax breaks are granted per person, not per property. Put the loan and the property in both names, and the second spouse gets their own full 80C and their own full Section 24(b), doubling the household’s deductible pool from Rs 3.5 lakh to Rs 7 lakh. ...

Most teams look at the 24-hour SLA on batch APIs and stop reading. That is a mistake. The word “batch” makes people picture overnight mainframe jobs and 1990s ETL, so they never do the arithmetic. Here is the arithmetic: Anthropic and OpenAI both give you a flat 50 percent discount on input and output tokens if you are willing to accept an asynchronous completion window instead of a synchronous response. That is not a routing trick or a caching hack. It is the same model, the same quality, half the bill, in exchange for latency you were probably not using anyway. ...

Almost every salaried person knows the Rs 1.5 lakh under 80C and the extra Rs 50,000 under 80CCD(1B). Far fewer know that there is a third NPS deduction with no upper cap tied to a rupee figure at all - and that it is one of the only real tax deductions still alive in the new tax regime. That deduction is Section 80CCD(2), the employer’s contribution to your NPS. If you are on the new regime (and most people now are, because the 2025 slabs made it the default), your 80C and 80CCD(1B) deductions are gone. 80CCD(2) survives. That makes it the single most valuable deduction a salaried employee can still get, and the majority of people leave it on the table because it needs one thing they never do: a conversation with HR. ...

Reddit reads like three easy problems stapled together. Posts in communities: a table. Voting: a counter. Comments: a tree. Say it out loud and the interviewer starts pulling threads. “A vote must feel instant but the displayed score must not be a live sum of a billion rows.” “The front page is sorted by hot, which is a function of both score and age, so the sort order of every post changes every second even when nobody votes.” “One popular post has 40,000 comments nested twelve levels deep and must paginate.” “A brigade of 5,000 bot accounts can drive a post to the top of a subreddit in ninety seconds, and you have to notice before it happens.” ...

Stack Overflow looks like a CRUD app. Post a question, others post answers, everyone votes, one answer gets accepted, and a number next to your name goes up. Say that in an interview and the follow-ups arrive fast. “The question page is read a thousand times for every time it is written, and it must show a live-ish score, the accepted answer pinned first, and the rest sorted by score - all in under 200ms.” “Reputation is a running total over every vote you have ever received; you cannot re-sum a billion vote rows on every profile load.” “Search is not a LIKE '%...%' query - a user typing python list comprehension slow must get the canonical answer ranked above ten thousand near-duplicates, and that ranking blends text relevance with votes, recency, and acceptance.” “There are 100M questions and 1B answers; that does not fit on one box.” ...

People hear “build Zoom” and reach for the WebRTC tutorial: two peers, an SDP exchange, media flows directly, done. That works for a 1:1 call and detonates the moment a third person joins, and it is not even in the same universe as a 1000-person all-hands. The core problem in video conferencing is not “how do two browsers connect” - that is solved by WebRTC and I have written about it elsewhere. The core problem is fan-out of live media in a room of N participants under a hard sub-200ms latency budget, and the topology you pick to solve it - mesh, MCU, or SFU - determines whether the product exists at all. ...

Here is a claim that will annoy most people building agents right now: your agent does not have a bug, it has a state problem. The infinite loop, the duplicate refund, the “I already did that” confusion, the run that cannot be resumed after a crash - none of these are model failures. They are what happens when the only record of what an agent has done lives inside a growing pile of chat messages that nobody can query, restart from, or reason about. ...

A shopping cart sounds like a toy problem. “Store a list of item IDs and quantities for a user, let them add and remove, show it back.” You could do it with a row per user and a JSON blob and be done in an afternoon. Then the interviewer starts adding constraints and every easy answer falls over. The cart has to follow the user from their phone to their laptop to the Alexa in the kitchen, and show the same items on all three within a second. It has to survive the user closing the tab and coming back a week later. It has to stay writable during a Prime Day sale when a hundred million people are hammering “add to cart” on the same few thousand doorbusters at the same instant. And - the hard one - the cart cannot lie about inventory: if the warehouse has 100 units of a limited item, you must not let 500 people put it in their cart, walk to checkout, and each expect it to be there. ...

“Move 1PB to the cloud” sounds like a copy job, and people design it like one: point a script at the source, rsync to an S3 bucket, wait. Then the interviewer drops the two numbers that change everything. The link is 10 Gbps. The files are in active use during the migration. Now do the arithmetic: at 10 Gbps, wire-speed and perfect, 1PB takes about 9.5 days of continuous transfer. Real throughput after overhead and contention with production traffic is half that, so ~20 days. And for those 20 days the source data keeps changing underneath you, so whatever you copied on day one is already stale by day two. ...

People hear “build Slack” and reach for a chat toy: a messages table, a WebSocket, insert on send, push to whoever is connected. That works for a demo and falls apart the instant you write down the real numbers. The largest org has 100K members. A single busy channel in that org - #general, #incidents, #announcements - can have tens of thousands of people watching it live. When someone posts, who do you deliver to, and how? Do you write a copy of that message into 50,000 inboxes (fan-out on write) and drown on a viral post, or do you store it once and make every reader come find it (fan-out on read) and drown on the read side instead? That single question - how a message gets from one sender to N readers - is the spine of the whole design, and Slack’s answer is different from Twitter’s or Facebook’s because Slack’s unit of delivery is the channel, not the follower graph. ...

A new embedding model drops, the benchmarks look great, and someone on your team changes one line of config to point at it. Nothing crashes. The pipeline runs. Queries return results. Latency is fine. Two weeks later, support tickets pile up about the assistant “getting dumber,” and nobody can find a deploy that explains it. This is the most common self-inflicted RAG outage I have seen, and it is entirely invisible to normal monitoring. Swapping embedding models does not throw an error. It quietly corrupts the geometry your retrieval depends on, and the only symptom is answers that are subtly, then badly, wrong. ...

There is a very common two-fund starter portfolio doing the rounds on Indian finance forums: put money into a Nifty 50 index fund and a Nifty Next 50 index fund, usually 50-50, and feel diversified because you now “own 100 stocks.” The pitch sounds airtight. Fifty large caps plus the next fifty, no stock repeated, double the names. Here is the uncomfortable part. Those two funds together are, almost to the constituent, the Nifty 100 index. You have not built a clever diversified portfolio. You have rebuilt an off-the-shelf index by hand, paid for the privilege of running two funds, and in the 50-50 version you have quietly made a large active bet without realising it. This post works the actual numbers: how much weight the second fund really carries, why “100 stocks” is a diversification illusion, where the genuine diversification actually comes from, and when one fund does the job better. ...

When you buy a term plan online, the last screen before payment offers you an “Accidental Death Benefit” rider. Rs. 50 lakh of extra cover for about Rs. 1,800 a year. It feels like a no-brainer, so most people tick the box. Here is the uncomfortable part. That rider covers the one accidental outcome you are already insured against, and skips the one that will actually ruin you financially. If you die in an accident, your family gets a cheque either way. If you survive the accident but can never work again, the rider pays nothing. ...

Everyone models an ad server as a lookup: “the user opens the feed, we fetch an ad, we show it, done.” The interviewer lets that sit for a moment and then piles on the constraints that make it a real system. There are not ten ads to choose from, there are millions of live campaigns; the best ad for this user has to be chosen from that pool in under 50 milliseconds while the feed is already rendering; advertisers set budgets and if you overspend theirs you eat the cost, if you underspend it you lose their trust and their business; the spend has to be paced evenly across the day, not blown in the first hour; a large fraction of clicks are bots and you must not charge advertisers for them; and all of this runs at 100 billion impressions a day. An ad server is not a lookup. It is a real-time per-impression auction over a targeted candidate set, constrained by budgets and paced over time, with a fraud filter in the loop - and the ad shown is just its output. ...

Almost everyone reaches for Google Docs the moment they hear “document editor,” and almost everyone is answering the wrong question. Google Docs is a real-time collaboration problem: two people typing into the same sentence at the same millisecond, operational transforms, CRDTs, convergence. That is a specific and hard sub-problem, and it is not what Notion or Wikipedia are. Notion and Wikipedia are async document systems: you open a page, you edit it, you save it. Someone else might edit it an hour later, or a minute later, but the design does not live or die on sub-200ms convergence of concurrent keystrokes. It lives or dies on three other things - how you store a document made of structured blocks, how you keep a full version history without exploding storage, and how you search across tens of millions of documents fast. ...

A car drives through a toll lane at 30 km/h, an overhead antenna reads its RFID tag, and by the time the nose of the car reaches the barrier the boom has lifted and a rupee amount has left a prepaid wallet. That is the whole product in one sentence, and the interviewer will let you feel good about it for about a minute before pointing at the parts that are actually hard. The barrier has to decide in under half a second while the wallet that funds the toll lives in a different bank’s ledger a network hop away. The same tag gets read three times because the car crawled under the antenna. The plaza in a valley loses connectivity for twenty minutes and cars keep coming. And the one thing that absolutely cannot go wrong - the number in the wallet - has to stay exactly right across 100 million debits a day even though two lanes, a retry, and a settlement job might all touch the same balance at once. ...

The network will lie to you. A client sends POST /charges, the server charges the card, and then the response is lost to a dropped connection, a load balancer timeout, or a client that gave up at 30 seconds. The client has no idea whether the charge happened. So it retries. Now you have charged the customer twice, and no amount of careful transaction code on the server prevented it, because the duplicate came from outside your database. ...

Most teams reach for a bigger database instance long before they reach for a connection pooler. That is backwards. A surprising amount of “Postgres is slow under load” is not Postgres being slow. It is Postgres drowning in connections, each one costing 5 to 10 MB of memory and a backend process, while your application opens a fresh connection for every request and throws it away a few milliseconds later. ...

“Design a flash sale” sounds like a shopping-cart problem until you write down the actual numbers: Burger King runs a promo, the app has 50 million people who will all tap the same button in the same minute, and there are exactly 6,000,000 free-burger coupons to give away. Not 6,000,001. Not 5,999,998. Exactly six million, then the button says “sold out” and everyone else goes home. The interviewer is not testing whether you can serve a page. They are testing whether you can run a single shared counter down from 6M to 0 under a 50-million-user stampede without ever letting it go negative, without handing one person two coupons, and without the whole app falling over. ...