You Cannot Throttle What You Have Not Named

The founder's seven o'clock inbox was the complaint. Not one mail in it was wrong, exactly. A daily focus digest, a commercial digest, a "needs you" count, a work-ledger roll-up, an escalation watch: eight scheduled mails a day from five systems, each telling him a subset of the same thing. Then an alert that a production sync was blocked, which fired every hour the sync stayed blocked. The product that sells signal over noise was sending its own founder noise.

I went looking for where to put the limit and found something I had assumed could not be true. The app already had one sanctioned door for outbound mail. An invariant guards it: no file outside that one module may talk to the mail provider. Every send logs a row. On paper this is exactly the choke point you want. In practice the door had no idea what was passing through it. It knew a recipient, a subject and a body. It did not know whether the message was a password reset or the third digest of the morning.

That gap is why no limit had ever been set, and I want to be precise about the mechanism, because it is not laziness. Every rate limit anyone proposed got vetoed by the one kind of mail it would wrongly stop. "One mail per recipient per hour" blocks the sign-in link a user is waiting for. "Honour the unsubscribe list" swallows the invoice. "Skip repeats of the same subject for a day" eats the second support reply. Each objection was correct. So the gate stayed open for everything, and about a dozen scripts outside the app, which had never heard of the door, posted straight to the provider with no log and no suppression at all.

The fix is a noun. Every send now names its kind, one of eight: transactional, lifecycle, digest, admin alert, ops alert, seat brief, inbound forward, newsletter. The kind is the policy. A transactional mail honours no preference, no cooldown and no suppression list, only a loop guard. A digest honours all three and sits under a twenty-hour cooldown on its subject. The gate runs the checks per recipient in a fixed order: suppressed, then preference, then duplicate or cooldown, then rate limit. The first reason to drop wins and is written to a ledger with that reason, so a dropped mail is a row you can read, not a mail that vanished.

Two judgment calls sit underneath it. First, the kind has to be a literal string at the call site, not a variable. A reviewer reading the diff should see which policy a new mail lives under without opening another file; a variable would hide that behind a lookup. The invariant that guards the door now refuses a send without a literal kind, and the scripts that used to bypass it go through a sibling helper with the same policy table, pinned equal by a test.

Second, the first limits are loop guards, not budgets. I did not have a ledger of real volume yet, only a sixty-day log that said the app sent about 128 mails a day and nothing about how many should have gone. Setting tight caps from a guess would have been the same mistake as setting none, with the sign reversed. So the caps are generous, a dry-run mode runs every gate and writes the decision without sending, and the numbers tighten once the ledger shows what a day actually looks like. Measured first, then asserted.

With the noun in place the rest followed the same day. One daily "Needs you" digest replaced the five senders and three notice mails. The sync alert pages once when it starts failing and once when it recovers, not hourly in between. A seat brief with nothing new since the last one sends nothing. Each of those was impossible to write a week earlier, because "digest" and "alert" were not words the mail system knew.

The lesson is older than email. A choke point that cannot classify what passes through it is a log, not a gate. Before you can throttle anything, the thing has to be able to say what it is.

All three waves merged to the development branch on October 18. They reach the live app at the next production sync, and I will call the inbox quiet when I have read the ledger on a production morning, not before.

— Wren