For a request counter nearing its fixed-width ceiling, when do you pick checked, saturating or wrapping arithmetic?

## Three answers to one question Every fixed-width arithmetic operation faces the same moment: the true result does not fit. There are exactly three useful responses, and choosing among them is a design decision that should be made deliberately per quantity rather than inherited from whatever the default operator does. **Wrapping** returns the result modulo 2^width. It is exact, total, branch-free, and the default in most fixed-width models. It is *correct* — not merely tolerable — when the quantity being represented is itself modular: a protocol sequence number, an index into a ring buffer of power-of-two capacity, a hash mixing step, a monotonic-clock difference where subtracting two wrapped readings unwraps to the right elapsed time. In those cases the wraparound is the semantics, and widening the type would be the mistake. **Saturating** clamps at the extreme of the range. Adding to a maximum leaves it at the maximum. It is total and cheap (a comparison, often a single instruction), and it preserves two properties people rely on: the result stays in range, and the sequence stays monotone. What it loses is accuracy, silently. A saturated counter reads exactly like a counter that legitimately sits just under the ceiling. **Checked** refuses to return a value at all when the true result does not fit, signalling instead — an exception, an error result, an absent value. It is the only option that preserves the guarantee "any number you receive from this arithmetic is the true number". It costs a branch per operation and, more significantly, it costs an error path at every call site. ## Applying that to a rate limiter's counter A rate limiter counts requests in a window and denies once the count passes a limit. Ask what each policy does when the count reaches the type's ceiling — which happens precisely during the traffic event the limiter exists to survive. - **Wrapping fails open.** The counter jumps from its maximum to the most negative value, which is below any limit, so the limiter starts admitting everything. The failure mode is maximally correlated with the emergency: the protection disappears at the peak. This is the choice to argue hardest against. - **Saturating fails closed.** The counter pins at the ceiling, stays above the limit, and keeps denying. The number in the metrics is wrong — understated — but the *decision* stays correct. For a limiter, whose output is a boolean, a saturating counter is safe in a way it would never be for a billing total. - **Checked fails loudly.** The increment signals, and now someone must decide what an unincrementable counter means. If the handler's answer is "deny and alert", it is saturating with an alarm attached, which is often exactly right. If there is no thought-through handler, checked arithmetic converts an accuracy bug into an availability incident. The general rule that falls out: **choose the policy whose failure direction matches the consequence.** Values that gate access should degrade toward denial. Values that are reported should degrade toward a signal, never toward a plausible lie. Values that are genuinely modular should wrap and say so in a comment. ## Why policy is the second move, not the first Before choosing a failure behaviour, remove the failure. A 64-bit counter incremented a million times a second takes on the order of 290,000 years to reach its ceiling. The engineering answer for almost every counting problem is therefore to size the type so the ceiling is unreachable within the value's lifetime, and to reset per window so the lifetime is short. Policy then covers the residual: quantities that legitimately can reach the ceiling (a product of user-supplied factors, an unbounded aggregation), and quantities pinned to a narrow width by an external format you do not control. Operationally, add headroom monitoring: export the value as a fraction of its type's maximum and alert at, say, half. That converts a cliff into a gradient and gives you a rewrite window rather than an incident. ## Costs worth knowing Checked arithmetic's per-operation branch is predictable and typically invisible outside tight numeric inner loops; the real cost is organisational, since every site now has two outcomes. Saturating arithmetic is nearly free but destroys the invariant that a difference of two counter readings equals the number of events between them, which silently breaks any consumer computing rates from deltas. Wrapping is free and correct only under a documented modular contract — the moment it is used as a general-purpose "we hope it is big enough", it is the worst of the three because its wrong values look like ordinary small numbers. A final portability note: numeric models differ in what they even offer. Some ecosystems give arbitrary-precision integers that grow rather than wrap, so the policy question does not arise for the default type and re-appears only at storage and wire boundaries; Python and Ruby sit there, while Java, Go and Rust are fixed-width and expose checked and saturating operations explicitly. Code moved across that boundary needs its counters re-examined, because the same expression carries different guarantees on each side.