Distributed Rate Limiter & API Gateway
Multi-tenant API gateway: token-bucket and sliding-window quotas across a consistent-hash shard ring, with Raft election covering shard failure.
Use case
The problem space.
Keep per-tenant quotas accurate across replicas and regions while a noisy neighbour, a lost shard or a region blip is in progress.
What's implemented
Built with intention.
Dual limiting strategies01
Token-bucket for smooth burst control and sliding-window counters for stricter endpoint policies.
Resilient control plane02
Consistent-hash sharding keeps a tenant on a stable limiter shard; Raft election promotes a replacement leader on failure.
Observable delivery03
gRPC and REST APIs expose decisions and quota status, while Prometheus metrics feed Grafana and a live React dashboard.
Architecture
Systems in concert.
The primary request and data paths, presented as a compact operating model.
A conceptual architecture for communicating the system design and operational responsibilities.
Step by step
From zero to
running.
Representative local-development commands that show the implementation path and operating sequence.
- 01
Bring up the data plane
Start Redis and PostgreSQL locally; apply the tenant-policy schema before launching the gateway.
docker compose up -d redis postgres make migrate - 02
Start a shard
Run a gateway replica with the desired node identity and consistent-hash ring configuration.
go run ./cmd/gateway --node gateway-1 --config ./configs/local.yaml - 03
Attach the dashboard
Install the dashboard dependencies and point it at the REST metrics endpoint.
cd dashboard && npm install && npm run dev - 04
Prove the envelope
Exercise both a burst and sustained-load profile, then inspect p99 latency and rejected requests.
k6 run tests/rate-limit.js kubectl get pods -n gateway