SysPadExamples › Rate limiter

Rate limiter

Sliding-window rate limiting at the edge. A limiter fleet checks and increments a sharded Redis counter before requests reach the backend, with live-updatable rules and an async metrics pipeline.

Why the counter store, not the backend, is the bottleneck: allowed and throttled traffic both hit it, so it saturates first under combined load.

Clients Users Rules Admin Users API Gateway API Gateway Rate Limiter Fargate Rules Store DynamoDB Counter Cluster ElastiCache Backend API EKS App Cache ElastiCache App Data Aurora Decision Events Kinesis AT LIMIT Metrics Aggregator Lambda Metrics Lake S3

How it works

Rules Store
Per-client and per-API limits. Admins update it live; the limiter fleet reads it rarely (cached in process).
Counter Cluster
The real bottleneck: every allowed AND throttled request checks a counter here, so it sees more load than the backend it guards. Sharded, and replicated for HA.

Request flows

Allowed request

  1. Clients
  2. API Gateway
  3. Rate Limiter
  4. Rules Store
  5. Counter Cluster
  6. Backend API
  7. App Cache
  8. App Data

Throttled request

  1. Clients
  2. API Gateway
  3. Rate Limiter
  4. Rules Store
  5. Counter Cluster

Decision metrics

  1. Clients
  2. API Gateway
  3. Rate Limiter
  4. Decision Events
  5. Metrics Aggregator
  6. Metrics Lake

Rule update

  1. Rules Admin
  2. Rules Store

Other interview practice

Open this architecture in SysPad · All examples