The previous piece treated a limit as a message to one caller. The other half of the question is what happens between callers, because a shared system without deliberate fairness isn’t neutral — it’s first-come, first-served, which reliably means the customer with the most automation gets the most capacity. Everyone else experiences that as the product being slow, with no visible cause and nothing they can do about it. Their traffic didn’t change; someone else’s did.

The default is worse than it sounds because heavy usage is usually not malicious. It’s a customer who wrote a nightly sync that fans out across their whole account, or a new integration that polls where it should subscribe. From their side they’re just using the product. From the system’s side they’ve quietly claimed a large share of a fixed pool, and the mechanism that lets them do it is the absence of any rule that says otherwise. Fairness doesn’t emerge; it has to be a thing someone implemented.

Implementing it means deciding what unit fairness applies to, which is a real design decision. Per customer is the obvious one, but a large customer legitimately needs more than a small one, so equal shares aren’t fair either. Per plan tier, weighted by contract, per-user within an account, per operation class — all defensible, all producing different outcomes, and the choice encodes an actual position on what the product owes whom. The important part is having a position at all, because the absence of one still produces an outcome: whoever pushes hardest wins.

There’s a second decision underneath: what to do when the pool really is exhausted. Slowing everyone down equally is one answer, and it’s often the wrong one, because it converts one customer’s spike into everyone’s degradation. Rejecting the excess above a fair share is usually better — the heavy user gets limited, everyone else stays fast, and the failure lands where the cause is rather than being spread evenly over the innocent. That’s load shedding, and the reason it feels uncomfortable is that it means deliberately failing requests you could technically have served, which is exactly the tradeoff being made either way; the only question is whether it’s made on purpose.

Which connects back to the previous piece. A limit is a message to one caller about what’s acceptable; fairness is the policy that decides whose requests get served when there isn’t room for everyone. Both are usually implicit, both are read by customers as facts about the product, and both are much easier to choose deliberately at design time than to retrofit after the first customer notices their afternoon got slow for reasons that had nothing to do with them.