A billion a month, for eight years.

At a thousand a day you fix bugs. At a billion a month, a defect affecting one tenth of one percent has touched a million recipients before anyone opens a dashboard. The arithmetic stops being reassuring and starts being the design constraint.

So you build differently, and the first thing to abandon is the instinct to log everything. At this volume full-fidelity logging costs more than the thing it observes and is still unreadable. Nothing is verified by looking at it, because nobody can look at a billion of anything. Every stage reports its own error rate instead, sampling becomes the only honest observability, and the question changes from "did it work" to "what fraction of it did not, and is that fraction moving".

This is the habit that transfers to every other system I have built since. The three exchanges all measure themselves for the same reason: at volume, the absence of an alarm is not evidence of anything.

Eight hundred addresses across a hundred domains on distributed farms is not one large machine. It is a fleet, and fleets have properties single servers do not: capacity that has to be planned rather than provisioned, isolation so one misbehaving tenant cannot degrade the others, and rotation so no single path carries more than its share.

The failure mode that actually bites is contagion. Shared infrastructure means one bad actor's traffic becomes everyone's problem downstream, and by the time it shows up in your own numbers the cause is three days old and somebody else's.

Which is why isolation is designed in at the start. Retrofitting it means migrating live traffic, and migrating live traffic at volume is how outages happen.

Every large receiver scores you. That score is not published, it changes without notice, it is held per-path rather than per-company, and it decides whether your traffic arrives at all. You cannot query it. You can only infer it from what comes back.

So it becomes infrastructure state: something you track, trend, and treat as a first-class input to routing decisions. I built the tooling for that — a custom suite that watched the signals available and fed them back into how traffic was distributed.

The general lesson is the useful one: when a critical dependency is opaque, you do not get to ignore it. You build the best model of it you can and you instrument the model.

The data platform underneath held sixty million user records with more than fifty behavioural attributes each. The obvious design is to precompute segments overnight and hand out lists. It is also wrong, because a list is a photograph and behaviour is a film — by the time the list is used, some fraction of it describes people who no longer match.

Segments were defined as rules and evaluated at the moment of use instead. That is more expensive per query and correct at the point where correctness matters, and it is the same decision I made again years later in a different product.

At this size, the schema is the product. Adding a fifty-first attribute is a migration across sixty million documents, so you think about it before you agree to it.

Revenue went from ₹1.8 crore to ₹20 crore over that period. The largest single contributor was not a new product, more volume, or better pricing. It was noticing that engagement behaviour already sitting in the platform described a segment nobody was selling against, and then building the thing that sold against it.

I mention it because it is the part people underrate. Running infrastructure at scale gives you a dataset most companies would pay for, and the returns come from asking it a commercial question rather than an operational one.

Finding the thing worth building is a different skill from building it. Most engineering organisations are well supplied with the second and short of the first.