HTTP 429 Too Many Requests vs gRPC 8 RESOURCE_EXHAUSTED
HTTP 429 and gRPC RESOURCE_EXHAUSTED both signal rate limiting, but gRPC's code is broader. HTTP 429 specifically means the client sent too many requests, while gRPC RESOURCE_EXHAUSTED covers rate limits, quota exhaustion, and server resource depletion (memory, disk, connections).
Description
The user has sent too many requests in a given time (rate limiting). The response should include a Retry-After header.
When You See It
When hitting API rate limits or making too many requests too quickly.
How to Fix
Check the Retry-After header. Implement exponential backoff. Consider caching responses.
Description
Some resource has been exhausted, perhaps a per-user quota, or the entire file system is out of space.
When You See It
A rate limit was hit, a quota was exceeded, or the server ran out of memory/disk. Common with API rate limiting and resource quotas.
How to Fix
Implement exponential backoff and retry. If quota-related, request a quota increase or optimize your usage pattern to stay within limits.
Key Differences
HTTP 429 is specifically about request rate — the client sent too many requests in a time window.
gRPC RESOURCE_EXHAUSTED covers rate limits plus quota exhaustion, memory pressure, and disk space.
HTTP 429 should include a Retry-After header; gRPC uses retry-after-ms or retry metadata.
gRPC RESOURCE_EXHAUSTED may indicate a server-wide capacity issue, not just per-client throttling.
For per-client rate limiting, both are equivalent; for server resource issues, gRPC is more versatile.
When to Use Which
Return HTTP 429 when a specific client exceeds its rate limit. Return gRPC RESOURCE_EXHAUSTED when a client exceeds its rate limit, quota, or when the server runs out of resources (memory, connections). In gRPC-to-HTTP gateways, map RESOURCE_EXHAUSTED to 429 for rate limits or 503 for server-wide resource exhaustion.