🚦 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!)