A merchant integration on your payments platform ships a bad deploy, and its retry loop starts hammering your charge endpoint a few thousand times a minute. Nothing is under attack, nothing is compromised, and that one merchant's traffic is still slowing down checkout for everyone else on the platform.

Rate limiting deliberately rejects requests from a named caller once they exceed an allowance measured over a window. The decision is fixed in advance, so the platform is not asking "am I struggling right now?" but "have you already had your share of this minute?"

Rate limiting appears in both product-style and infrastructure-style interviews, usually as five to ten minutes inside a broader design and occasionally as a whole round at API-platform companies. A complete answer names a counting algorithm, defines what a rejected caller receives, and explains what changes when twenty service instances must share the counter. The first implementation many people choose fails under horizontal scaling in a way that two numbers make clear.

Settle the decisions in this order: define the limit, choose a counting algorithm, choose the key and response contract, then decide how to enforce the count across nodes and handle limiter failures. TCP congestion control is the transport-layer relative of the same idea and stays out of scope. The examples use one payments platform where each merchant integration holds an API key, and endpoints range from cheap reads to expensive writes.