Posts

The default advice for parking cash you will need in 3 to 12 months is a liquid fund. It is safe, it redeems fast, and it beats a savings account. Almost nobody stops to ask whether it is the best post-tax option, because “liquid fund” has become a reflex. For a 30% bracket investor, the reflex is wrong. An arbitrage fund earns roughly the same gross return as a liquid fund but is taxed as an equity fund, and that single accounting fact is worth about 0.7% to 2% extra per year after tax. Nobody markets this because there is no product being sold - it is just a tax quirk sitting in plain sight. ...

“Send the user a notification” sounds like one function call. Then you write it down. Which channel - push, email, SMS, in-app? What if the user turned push off but left email on? What if APNs is down for ten minutes? What if the order service retries and now the user gets charged-confirmation SMS three times? What if a bug in one service starts emitting a million notifications a second and you SMS your entire user base at a rupee each? The one-line function is actually a distributed system with a fan-out, a provider integration layer, a retry engine, a preference store, and a rate limiter, and every one of those is a place it breaks. ...

Everyone thinks the rate limiter is a for-loop with a counter. “Count requests per user per minute, reject when it goes over 100, done.” Then the interviewer asks the questions that actually matter: which algorithm, where does the counter live when you have 40 API servers behind a load balancer, how do you stay accurate when two servers increment the same user’s counter at the same millisecond, and how much latency does this add to every single request in the system. Now it is a real problem. ...

“Design Uber” sounds like a CRUD app with a map on top. A rider taps a pin, a driver shows up, money moves. The interviewer lets you believe that for about thirty seconds, then asks the question that breaks the toy version: there are 5 million drivers on the road right now, each one broadcasting its GPS position every few seconds, and a rider standing on a corner wants the nearest available car in under a second. How do you find “the closest driver” out of millions of constantly-moving points, hundreds of thousands of times per second, without scanning the whole planet on every request? ...

The most common mistake in LLM apps is treating the model as the safety layer. You write a careful system prompt, add “do not answer off-topic questions, do not produce harmful content, always return valid JSON,” and ship it. Then a user asks your customer-support bot for medical advice, it hands out a dosage, and you learn that a system prompt is a suggestion, not a contract. Guardrails are the code that sits around the model and turns suggestions into constraints. The model is a probabilistic text generator. Everything you actually guarantee has to be enforced outside it. This post builds a guardrail pipeline from the naive version to something you can put in front of real users, with a clear answer to the question that matters: what does each layer catch that the others miss? ...

The standard advice is a one-liner: your home loan is at 8.5%, equity returns 11-12% over the long run, so never prepay - invest the surplus and let the gap compound in your favour. It sounds airtight and it is repeated everywhere. It is also often wrong, because it quietly assumes the entire interest you pay is tax-deductible. On a large home loan in the early years, most of it is not. The Section 24 cap of Rs. 2 lakh is where the clean story falls apart. ...

The most productive engineers I know stopped bragging about how fast they type. When a coding agent can produce 400 lines of correct code from a paragraph, typing speed is not the bottleneck anymore. The bottleneck is the paragraph. If the paragraph is vague, you get 400 lines of confidently wrong code, fast. If the paragraph is precise, you get something you can ship. The spec is now the leverage point, and most people are still treating it like a throwaway comment. ...

Most teams pick an embedding model the same way they pick a sorting algorithm: look up the benchmark, take the top result, ship it. For sorting algorithms that works fine. For embeddings it reliably produces a retrieval system that looks great on paper and underperforms on the actual product. The MTEB leaderboard is not useless. But it is measuring retrieval on academic corpora with clean, well-formed queries against documents that look nothing like your internal docs, your customer support tickets, or your codebase. Ranking third on MTEB while being the worst model for your domain is entirely possible, and it happens constantly. ...

Everyone thinks the URL shortener is a trivial problem. “It’s a hash map. Store long URL, return short URL, done.” Then the interviewer asks: how do you generate the key, how do you avoid collisions, what happens when one popular link gets 50,000 redirects a second, and how do you serve that redirect in under 10ms across the globe. Now it’s a real system. The whole problem is deceptively read-heavy and deceptively about one decision: how you mint short keys. Get the key generation wrong and everything downstream (collisions, hot shards, wasted storage) gets worse. Get it right and the rest is caching and sharding you already know. ...

The Twitter timeline looks trivial until you say the numbers out loud. “Show me a list of tweets from people I follow, newest first.” It is a join. SELECT * FROM tweets WHERE author IN (my followees) ORDER BY time DESC LIMIT 50. Done. Then the interviewer points out that some users follow 5,000 accounts, some accounts have 100 million followers, the timeline must load in under 200ms, and 300 million people refresh it all day. The join is now the most expensive query on the internet. ...

A chat app sounds like the easiest system you will ever build. “User A sends a message, user B receives it.” One INSERT, one SELECT. The interviewer lets you say that, then asks the questions that turn it into one of the hardest real-time systems in the building: how does B receive it instantly when B might be offline, on a train, or logged in on three devices at once? How do you show the second grey tick the moment it lands on B’s phone, and the two blue ticks the moment B actually opens the chat? How do hundreds of millions of phones hold an open connection to your servers at the same time without melting? ...

A 1% expense ratio sounds harmless. It is less than what Zomato charges in delivery fees, less than a bank locker’s annual rent. Surely it is not worth losing sleep over. Run that 1% through 25 years of compounding and it does not cost you 1% of your corpus. It costs you 16% of your final wealth - roughly Rs 27 lakh per Rs 10 lakh invested, or Rs 24 lakh on a Rs 10,000/month SIP. The money does not disappear in a single charge you can see on your statement. It is silently extracted each year from a growing base, accelerating in rupee terms every single year. ...

The instinct when a task is complex is to throw more agents at it. Spin up a researcher, a writer, a critic, a planner - a whole crew. It feels like good engineering. It is usually not. Most multi-agent systems in production are slower, more expensive, and less reliable than a single well-designed agent. The coordination overhead is real: more LLM calls, more context to manage, more failure points, and latency that multiplies rather than shrinks. The only reason to use multiple agents is if the task structure genuinely requires it. Most tasks do not. ...

When your web service throws a 500, you have a stack trace. When your LLM app returns a bad answer, the status code is 200, the latency looks normal, and you have no idea what happened. That is the problem. Standard observability - error rate, latency percentiles, throughput - tells you nothing about the most common failure mode in LLM applications: the model returned something plausible but wrong. You need a different class of instrumentation, one that captures the full context of every inference call - what you sent, what the model returned, how many tokens it used, and which tools it called along the way. ...

“Nifty 50 SIP has historically returned 12-15% over 10 years.” You will see this claim in every mutual fund advertisement. It is not wrong, but it hides the most important part of the story. That 12-15% is an average across all possible 10-year windows. The actual outcome for any real investor depended entirely on which specific decade they happened to invest in. Two investors who each put in exactly ₹10,000 per month for 10 years in a Nifty 50 index fund - starting just five years apart - could have ended up with a difference of over ₹14 lakh on identical total contributions of ₹12 lakh. ...

The cheapest optimization most teams skip is not routing to smaller models or trimming the context window. It is not calling the model at all. When ten users ask “how do I reset my password?” your app pays to generate that answer ten times. Every one of those generations after the first is pure waste. Caching LLM responses is not a new idea, but most implementations are either too naive (exact-match string hashing that misses 90% of cacheable requests) or too aggressive (semantic matching that returns wrong answers). The gap between those two extremes is where production systems live, and it is worth understanding the mechanics before you build. ...

If you have a regex somewhere that strips markdown fences to pull JSON out of an LLM response, you have a time bomb. It works 95% of the time in development. It breaks on the 5% of production traffic that has slightly different phrasing, a model version bump, or a user input the model has never seen. You fix it, it breaks again three weeks later in a different way. ...

The question engineers ask most often when an LLM pipeline underperforms is: “how should I reword this prompt?” That is almost never the right question. The right question is: “what am I putting in the context window, and is it the right information in the right order?” This shift - from prompt wording to context construction - is what context engineering means. It is not a rebranding. The two disciplines require different skills, different tooling, and produce different categories of wins. A 10% improvement from rewording a prompt is about as good as it gets. A 40-60% quality improvement from restructuring how you build context is routine. ...

Most production AI costs are paid to frontier models for tasks that a 3-billion-parameter model running locally could handle just as well. Not the hard reasoning, not the creative synthesis - the classification, the extraction, the summarization of short content, the fill-in-the-template work that makes up the majority of real inference load. Small language models (SLMs) are not a compromise you accept when you cannot afford the real thing. In 2026, they are the deliberate choice for the 70-80% of tasks where frontier models are overkill, and the routing layer that separates them is the actual engineering problem worth solving. ...

Every LLM you have used in production generates text the same way: one token at a time, left to right, each token depending on everything that came before it. That is autoregressive decoding, and it has a hard constraint baked in. The sequential nature is not an implementation detail you can optimize away - it is the mathematical structure of the model. Diffusion LLMs take a different path. They generate an entire sequence in parallel across multiple denoising steps, rather than one token per step. The practical result is lower latency on long outputs. The catch is that the tradeoffs are subtle enough that most coverage of this topic either oversells the speed claims or undersells the real limitations. ...