1. Requirements Clarification (5-8 minutes)
   - Understand scale and constraints
   - Clarify functional requirements
   - Define success metrics

2. High-Level Design (10-15 minutes)
   - Draw system architecture
   - Explain major components
   - Discuss data flow

3. Deep Dives (20-25 minutes)
   - Algorithm selection
   - Distributed implementation
   - Database design
   - API design

4. Trade-offs and Alternatives (5-10 minutes)
   - Discuss different approaches
   - Explain design decisions
   - Address limitations

5. Follow-up Questions (5-10 minutes)
   - Handle variations
   - Discuss scaling
   - Security considerations

Essential Questions:
1. "What are we rate limiting? (Users, IPs, API keys, endpoints?)"
2. "What rate limiting algorithm should we use? (Token bucket, sliding window?)"
3. "What happens when limit is exceeded? (Reject, queue, throttle?)"
4. "Do we need different limits for different user tiers?"
5. "Should limits be configurable in real-time?"

Good Follow-ups:
- "How should we handle burst traffic?"
- "Do we need hierarchical rate limiting?"
- "Should we support allowlists/blocklists?"
- "What information should we return in rate limit headers?"

Scale Questions:
1. "How many requests per second do we need to handle?"
2. "How many concurrent users?"
3. "What's the acceptable latency overhead?"
4. "How accurate does the rate limiting need to be?"
5. "Do we need to support multiple geographic regions?"

Reliability Questions:
- "What's the target uptime?"
- "Should we fail-open or fail-closed?"
- "How do we handle Redis failures?"
- "What's the disaster recovery plan?"

❌ Bad Approach:
"I'll use Redis with Lua scripts for atomic operations..."

✅ Good Approach:
"Let me first clarify the requirements. Are we rate limiting 
per user, per IP, or both? What's the expected scale? 
Based on that, I'll choose the appropriate algorithm and 
storage solution."

Key Point: Always clarify requirements before designing

❌ Bad Approach:
"We'll just use a counter in Redis, increment it on each request."

✅ Good Approach:
"In a distributed system with multiple servers, we need to 
consider:
- Race conditions when multiple servers check the same counter
- Network latency to Redis
- Consistency vs availability trade-offs
- Clock synchronization across servers

I propose a hybrid approach with local counters and periodic 
sync to Redis for better performance."

Key Point: Show awareness of distributed system complexities

❌ Bad Approach:
"Token bucket is the best algorithm for rate limiting."

✅ Good Approach:
"Token bucket allows bursts which is good for user experience, 
but it can lead to sudden spikes that overwhelm downstream 
services. Alternatively, leaky bucket provides smooth output 
but poor UX. For this use case, I'd recommend token bucket 
with a reasonable burst size because..."

Key Point: Every design decision has trade-offs

❌ Bad Approach:
"We'll just count requests and reject when limit is exceeded."

✅ Good Approach:
"We need to handle several edge cases:
- Clock skew across distributed servers
- Network partitions between rate limiter and Redis
- Retry storms when clients retry failed requests
- Boundary issues with fixed window counters
- Race conditions with concurrent requests

For each of these, here's how I'd handle it..."

Key Point: Demonstrate thorough thinking

Strong Answer:
"I recommend the sliding window counter algorithm because:

1. Accuracy: 99%+ accurate, no boundary issues like fixed window
2. Performance: O(1) time complexity, only 2 counters needed
3. Memory: Low memory usage compared to sliding window log
4. Implementation: Simpler than sliding window log

The algorithm works by maintaining two counters:
- Current window counter
- Previous window counter

We calculate a weighted count based on how far we are into 
the current window. This gives us the accuracy of sliding 
window log with the efficiency of fixed window counter.

Trade-off: Slightly less accurate than sliding window log 
(99% vs 100%), but much more efficient."

Why This Works:
- Shows deep understanding
- Explains reasoning
- Discusses trade-offs
- Provides implementation details

Strong Answer:
"For distributed rate limiting, I propose a hybrid approach:

Local Enforcement (Fast Path):
- Each server maintains local counters in memory
- Check local counter first (<1ms latency)
- If usage < 80% of limit, allow immediately
- Covers 95% of requests

Redis Coordination (Accurate Path):
- When usage > 80%, check Redis for accurate count
- Use Lua scripts for atomic operations
- Sync local counters to Redis every 1 second
- Handles edge cases and ensures accuracy

Benefits:
- Low latency: 95% of requests served in <1ms
- High accuracy: 99%+ accurate with Redis coordination
- Scalable: No single point of failure
- Cost-effective: Reduces Redis load by 95%

Trade-off: 1-5% of requests might exceed limit during 
the 1-second sync window, which is acceptable for most 
use cases."

Why This Works:
- Balances performance and accuracy
- Shows system design thinking
- Quantifies benefits
- Acknowledges limitations

Strong Answer:
"For failure handling, I'd implement a tiered approach:

Tier 1: Redis Failure
- Fail-open for premium users (maintain service)
- Fail-closed for free users (protect backend)
- Use degraded limits (e.g., 10x normal limit)
- Alert operations team immediately

Tier 2: Network Partition
- Continue with local counters only
- Sync when partition heals
- Accept temporary inaccuracy
- Monitor for abuse patterns

Tier 3: Complete System Failure
- Bypass rate limiting entirely
- Rely on backend protection (circuit breakers)
- Emergency throttling at load balancer
- Incident response procedures

The choice between fail-open and fail-closed depends on:
- User trust level
- Backend capacity
- Business impact
- Security requirements

For a production API, I'd default to fail-open with degraded 
limits to maintain availability while still providing some 
protection."

Why This Works:
- Comprehensive failure analysis
- Practical solutions
- Business awareness
- Flexible approach

Strong Answer:
"Great question. For multi-region rate limiting, I see three 
approaches:

Option 1: Global Counter (Strong Consistency)
- Single Redis cluster, all regions check same counter
- Pros: 100% accurate
- Cons: High latency (100-300ms cross-region)
- Use when: Accuracy is critical

Option 2: Regional Quotas (Eventual Consistency)
- Divide quota among regions (40% US, 30% EU, 30% Asia)
- Each region enforces independently
- Periodic rebalancing based on usage
- Pros: Low latency (<5ms)
- Cons: 95-99% accurate
- Use when: Performance is critical

Option 3: Hybrid (Recommended)
- Regional enforcement with global coordination
- Fast path: Check regional quota
- Slow path: Sync to global counter every 10s
- Adaptive quota allocation
- Pros: Balance of speed and accuracy
- Use when: Need both performance and accuracy

For most use cases, I'd recommend Option 3 because it provides 
the best balance. The 1-5% inaccuracy is acceptable for most 
APIs, and we get the low latency that users expect."

Why This Works:
- Multiple solutions
- Clear pros/cons
- Practical recommendation
- Shows depth of knowledge

Strong Answer:
"I'd implement a comprehensive testing strategy:

1. Unit Tests:
   - Test each algorithm implementation
   - Test counter increment/decrement
   - Test edge cases (boundary conditions, race conditions)
   - Test failure scenarios

2. Integration Tests:
   - Test Redis integration
   - Test database operations
   - Test API endpoints
   - Test configuration updates

3. Load Tests:
   - Simulate 10M requests/second
   - Test with 100M concurrent users
   - Measure latency (P50, P95, P99)
   - Verify accuracy under load

4. Chaos Tests:
   - Kill Redis instances
   - Introduce network partitions
   - Simulate clock skew
   - Test failover scenarios

5. A/B Tests:
   - Test different algorithms
   - Test different limits
   - Measure user impact
   - Optimize based on data

Key Metrics:
- Latency: <5ms P99
- Accuracy: >99%
- Throughput: 10M req/s
- Availability: 99.99%

I'd also implement canary deployments to test changes on 
a small percentage of traffic before full rollout."

Why This Works:
- Comprehensive testing approach
- Specific metrics
- Practical strategies
- Risk mitigation

1. "Rate limiting is simple, just use a counter"
   → Shows lack of depth

2. "We don't need to worry about failures"
   → Ignores reliability

3. "100% accuracy is required"
   → Unrealistic in distributed systems

4. "Redis can handle everything"
   → Single point of failure

5. "We'll figure out scaling later"
   → Poor planning

1. "Let me clarify the requirements first"
   → Shows structured thinking

2. "Here are three approaches with trade-offs"
   → Demonstrates options analysis

3. "In a distributed system, we need to consider..."
   → Shows system design knowledge

4. "The accuracy-performance trade-off is..."
   → Understands trade-offs

5. "For this scale, we need to..."
   → Practical scaling approach

"To summarize, I've designed a distributed rate limiting system 
that:
- Handles 10M requests/second with <5ms latency
- Achieves 99%+ accuracy using hybrid local+Redis approach
- Scales horizontally across multiple regions
- Fails gracefully with configurable fail-open/closed
- Provides comprehensive monitoring and alerting

The key design decisions were:
1. Sliding window counter for accuracy and efficiency
2. Hybrid approach for performance and accuracy
3. Multi-layer defense for security
4. Eventual consistency for scalability

Areas for future improvement:
- ML-based anomaly detection
- Adaptive rate limiting based on system load
- More sophisticated quota management

I'm happy to dive deeper into any specific area."

Why This Works:
- Concise summary
- Highlights key decisions
- Shows forward thinking
- Invites discussion