Rate limits are backpressure with a policy

Unlimited is not a product plan

Without limits, one client can burn the shared pool for everyone. With crude limits, good clients get punished for normal spikes. The policy matters.

The useful signal is usually already there.

Systems stories get more interesting when you can feel the pressure move through the stack.

Limit by the thing that consumes capacity

Sometimes that is user id, API key, tenant, IP, endpoint, cost unit, or write path. Match the limit to the resource you are protecting.

A good limit includes a recovery hint.

Make rejection useful

Clients need status codes, retry headers, and docs. Operators need dashboards showing who is limited and why.

Flip the switches and watch the story turn into a tiny operating model.

Limits protect the promise

Rate limiting is reliability with manners: it preserves the service by making overload explicit.

source trail