The two pieces before this one covered what a limit says to a caller and how capacity gets divided between them. This last one is about time: limits are set once, against a snapshot of what the system could handle and what customers were doing, and then they sit there while both facts change. The infrastructure gets faster, the workloads get bigger, the customer base shifts toward the kind of user who needs more — and the number stays exactly where someone put it during an incident two years ago.

The result is a ceiling nobody is looking at. Customers hit it and work around it: they shard requests across multiple keys, they build retry loops that spread work across hours, they conclude that a use case isn’t possible and quietly do it somewhere else. None of that generates a support ticket saying “your limit is too low.” It generates strange traffic patterns, an integration that looks oddly inefficient, or an opportunity that simply never appears. The signal exists, but it doesn’t announce itself as being about the limit.

Which suggests the practical move: instrument how often limits are hit and by whom, and read it as product feedback rather than as evidence the protections are working. A limit that nobody reaches is either well-chosen or irrelevant. A limit that a handful of accounts hit constantly is a conversation — maybe they’re doing something inefficient you could help with, maybe they’ve outgrown the tier, maybe the cap is simply wrong now. What you don’t want is that number sitting in a dashboard nobody checks, quietly describing customers pressed against a wall you forgot you built.

The counterweight is that raising limits is asymmetric in the other direction. Every increase is easy to grant and hard to take back, because usage expands to fill it and someone builds a workflow that depends on the new headroom. This is the same dynamic as the config thread’s deferred decisions and the dead-code thread’s accumulation: the generous choice made casually becomes a permanent commitment made by nobody in particular. Raising a limit deserves the same deliberateness as setting it, including knowing what would happen if everyone used the new one.

So the thread closes where the first piece started, with limits as product surface rather than plumbing. They tell integrators what’s acceptable, they decide who gets served under contention, and they define the ceiling on what anyone can build. All three are decisions, all three get made by default if nobody makes them, and the default was chosen by whatever stopped an incident that nobody remembers. Reviewing them occasionally is cheap. Discovering years later that a number set in a hurry has been shaping your product’s ambitions is not.