Problem
structured-proxy fronts public REST surfaces of gRPC services. Deployments that expose transcoded routes to untrusted clients currently have to bolt rate limiting on elsewhere (upstream service or a separate gateway), which duplicates auth-context parsing and splits edge policy across components.
Proposal
Config-driven rate limiting middleware applied at the transcoding layer:
- Key extraction: configurable per route group; sources: authenticated principal (claim from validated JWT), API key header, client IP fallback for anonymous traffic
- Algorithm: GCRA (token-bucket equivalent, single stored timestamp per key) so legitimate burst traffic (page-render request fans) passes while sustained abuse is throttled
- Backends: in-process store (single replica) + Redis-protocol store (Redis/Dragonfly) for multi-replica deployments, selected in config
- Tiering: named limit profiles (
{ rate_per_min, burst }) referenced from route/principal matchers, so operators define tiers as data
- Response contract: 429 with
Retry-After and RateLimit-Limit / RateLimit-Remaining / RateLimit-Reset headers (draft-ietf-httpapi-ratelimit-headers)
Acceptance criteria
Estimate
3d
Problem
structured-proxy fronts public REST surfaces of gRPC services. Deployments that expose transcoded routes to untrusted clients currently have to bolt rate limiting on elsewhere (upstream service or a separate gateway), which duplicates auth-context parsing and splits edge policy across components.
Proposal
Config-driven rate limiting middleware applied at the transcoding layer:
{ rate_per_min, burst }) referenced from route/principal matchers, so operators define tiers as dataRetry-AfterandRateLimit-Limit/RateLimit-Remaining/RateLimit-Resetheaders (draft-ietf-httpapi-ratelimit-headers)Acceptance criteria
Estimate
3d