https://github.com/shahnotes/aws-rate-limiter-arch
Designing a Scalable Rate Limiter System on AWS
https://github.com/shahnotes/aws-rate-limiter-arch
architecture aws rate-limiter
Last synced: 10 months ago
JSON representation
Designing a Scalable Rate Limiter System on AWS
- Host: GitHub
- URL: https://github.com/shahnotes/aws-rate-limiter-arch
- Owner: shahnotes
- Created: 2025-06-17T17:59:55.000Z (12 months ago)
- Default Branch: main
- Last Pushed: 2025-06-17T18:00:22.000Z (12 months ago)
- Last Synced: 2025-07-19T22:11:36.264Z (11 months ago)
- Topics: architecture, aws, rate-limiter
- Homepage:
- Size: 2.93 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# 🚦 Designing a Scalable Rate Limiter System on AWS
## 💡 Problem
Design a rate limiter for:
- **Login attempts**: Max 3 in 10 minutes
- **Video views**: Max 20/day
- **Comments**: Max 100/day
Must support millions of users with low latency and high availability.
---
## 🎯 Functional Requirements
- Per-user and per-IP request limiting
- Configurable rules per API endpoint
- Real-time blocking if limit exceeded
## 🚫 Non-Functional Requirements
- Latency ≤ 20ms
- High throughput (10K+ RPS)
- 99.99% availability
- Low operational cost
- Horizontal scalability
---
## 🏗️ High-Level Design
```
[ Client ]
│
▼
[ API Gateway ]
│
▼
[ Rate Limiter (Lambda or ECS/Fargate) ]
│ ▲
│ │
▼ │
[ Redis (ElastiCache) ] ← stores counters
│
▼
[ DynamoDB ] ← stores config (limits per API)
```
---
## ⚙️ AWS Services Used
| Component | Purpose |
|------------------------|----------------------------------------|
| API Gateway | Entry point, optional usage plans |
| AWS Lambda (or Fargate)| Stateless compute for checking limits |
| ElastiCache Redis | Fast, atomic counters with TTL |
| DynamoDB | Stores API limit rules, fallback store |
| CloudWatch + X-Ray | Monitoring + tracing |
---
## 📊 Data Design
### Redis Keys (Per user/API)
```
user:123:/comments → Sorted Set [timestamp1, timestamp2...]
TTL: 24h
```
### DynamoDB (Rules Table)
```
PK: API:/comment | SK: default
Limit: 100 | TimeWindow: 24h
```
---
## 🧠 Algorithms
- **Fixed Window Counter** for login
- **Sliding Window (Sorted Set)** for comment and view tracking
- **Token Bucket** for smoother burst control (optional)
---
## 📈 Scaling and Resilience
- Redis is multi-AZ (clustered)
- Lambda scales automatically
- Fail-open for non-critical APIs (e.g., video view)
- Fail-close for critical ones (e.g., login attempts)
---
## 🔍 Observability
- CloudWatch custom metrics:
- Requests blocked
- Rule violations
- X-Ray for tracing Lambda execution
---
## ✅ Trade-offs Considered
| Option | Trade-off |
|-------------------|-------------------------------------------|
| IP vs User ID | IP is anonymous but prone to collisions |
| Redis vs DB | Redis fast but volatile; fallback to DB |
| Fail-open | Better UX, worse protection |
| Sliding vs Token | Sliding is precise, token is burst-friendly|
---
## 📌 Conclusion
This architecture:
- Handles real-time request limiting
- Is fully serverless (or containerized if needed)
- Leverages Redis + DynamoDB for speed and persistence
- Scales easily and is cost-efficient
---
### ⏱️ Pro Tip:
If you have **30 minutes** for this question:
- Spend first **5 mins** clarifying scope
- Next **10 mins** sketch out architecture & flow
- Last **15 mins** write structured answer like above
(Include trade-offs and AWS reasoning — this is what bar-raisers look for!)