GateKey
API key management SaaS with tiered rate limiting and a circuit breaker
Overview
What this is
GateKey is a full-stack SaaS platform for issuing and managing API keys, built for teams that need per-tier rate limiting, safe key storage, and resilience when downstream calls start failing.
Problem
Why it needed building
Homegrown API key systems usually get one thing right and skip the others — either keys are stored insecurely, rate limits aren't actually enforced under load, or there's no graceful behavior when a downstream service starts failing.
Solution
How it works
Keys are generated with a SHA-256 hashed, show-once pattern, so the raw key is never stored or retrievable after creation. Redis-backed sliding window rate limiting enforces separate Free (60 req/min) and Pro (1000 req/min) quotas. A circuit breaker trips to OPEN after 5 consecutive failures and auto-recovers through a 10-second HALF-OPEN state instead of hammering a struggling downstream service.
Architecture
How it's put together
- →SHA-256 hashed API key generation using a show-once pattern — raw keys are never persisted
- →Per-key Redis sliding window rate limiting enforcing tier-based quotas (Free vs Pro)
- →Circuit breaker with OPEN / HALF-OPEN / CLOSED states, tripping after 5 consecutive failures and auto-recovering after 10 seconds
- →Multi-tenant platform with strict per-user data isolation, verified across 4+ test accounts
- →Razorpay subscription billing with HMAC-SHA256 webhook signature verification across activated, cancelled, and halted lifecycle events
Challenges
The hard part
Getting the circuit breaker's recovery behavior right was the hardest part — recovering too eagerly reintroduces load onto a still-struggling service, recovering too conservatively leaves the gateway rejecting requests longer than necessary.
Trade-offs
What I gave up on purpose
The show-once key pattern means a lost key can only be rotated, never retrieved — a deliberate trade of convenience for the guarantee that a stolen database dump can't be used to derive a working key.
Performance
What changed, measurably
Gateway processing latency stays under 20ms excluding I/O. Rate limiting held tier quotas correctly under load (37 requests in 30s), with zero cross-tenant data leakage across test accounts.
Next
What I'd build next
Add usage analytics per API key so customers can see which endpoints and quotas they're actually consuming before they hit a limit.