Rate Limit

Overview

A Rate Limit is a policy that restricts how many requests, operations, or resource units a client may consume within a defined interval or capacity model. It differs from a business transaction limit because it controls service consumption rather than payment value or customer eligibility.

The main risks include retry storms, unfair shared quotas, hidden throttling, dropped critical requests, and clients that ignore backoff instructions. APIs and RPC providers use limits to protect availability, fairness, cost, and backend stability. The Rate Limit owner should publish stable error semantics and guidance on whether correction, retry, status lookup, or escalation is appropriate.

In production, teams should define ownership and apply published limit dimensions, client identification, 429 responses, Retry-After guidance, quota headers, burst policy, and fair tenant isolation. The Rate Limit contract should define identifiers, validation, authorization, status semantics, errors, limits, and version behavior at the same boundary.

Useful measures include throttled request rate, quota utilization, retry-after compliance, burst rejection rate, and limit-related failure rate. Rate Limit is closely connected to RPC Rate Limit, Exponential Backoff, and Request Timeout. Observability for Rate Limit should record operation, version, principal, request ID, latency, retry count, error code, and final state without exposing secrets.

Data handled by Rate Limit should use documented types, units, timestamp rules, nullable fields, and enum behavior to prevent silent interpretation errors.

For Rate Limit, the application should preserve a correlation path from request construction through response, asynchronous completion, and final business state. A successful transport result from Rate Limit should not be interpreted beyond the exact API state documented by the provider.