Idempotency & Back Pressure

Two problems show up together in every distributed system: work arrives more than once, and work arrives faster than you can do it.

Idempotency means applying an operation twice leaves the same state as applying it once. It matters because a client that times out cannot tell whether the request landed, so its only safe options are to retry or to give up — and giving up on a payment is not an option. The standard mechanism is an idempotency key: the client generates a unique id, the server records it with the result, and any retry carrying that key returns the stored result instead of doing the work again.

GET, PUT, and DELETE are idempotent by definition. POST is not, which is why creation endpoints need explicit keys.

Back pressure is a system telling its callers to slow down instead of silently queueing forever. Unbounded queues do not absorb overload, they hide it — latency climbs, memory grows, and eventually everything fails at once with a queue full of requests whose callers have already timed out. A bounded queue that rejects work is more honest and recovers faster.

Ways to shed load, in rough order of preference. Rate limiting caps input per client. Throttling slows everyone proportionally. Load shedding drops the least valuable requests first — health checks and paying customers survive, background refreshes do not. Queue-based load levelling puts a buffer between a spiky producer and a steady consumer, which smooths bursts but does not create capacity.

The rule that ties them together: if you are going to retry, be idempotent; if you are going to be retried, apply back pressure. A system that does neither converts one slow dependency into a full outage.