What you should do next
With requirements agreed, publish a timeboxed plan before drawing classes. Interviewers score the plan as much as the code.
45-minute timeline
| Phase | Clock | Output |
|---|---|---|
| Requirements | 0:00 – 5:00 | Functional + NFR + out-of-scope |
| Entities | 5:00 – 12:00 | Config, Result, Type |
| Interfaces | 12:00 – 20:00 | Strategy, ClockProvider, Manager, Factory |
| Algorithm trade-offs | 20:00 – 25:00 | Comparison table + pick |
| Implementation | 25:00 – 38:00 | Token Bucket + Manager + thread safety |
| Testing | 38:00 – 44:00 | Unit plan + concurrency stress idea |
| Wrap-up | 44:00 – 45:00 | Metrics, eviction, distributed next steps |
If they only want one algorithm, still name the others and why you did not pick them.
Delivery order (matches this course)
- Entities — immutable Config and Result
- Contracts — Strategy first, then Manager that routes by priority
- One algorithm deeply — Token Bucket with lazy refill
- Thread safety — per-client lock, not a global lock
- Optional — other algorithms behind the same interface
- Scale-out talk — why in-memory fails with multiple pods
Patterns you will use (name them)
- Strategy —
RateLimiterStrategyfor algorithms - Factory —
RateLimiterFactorymapsRateLimiterType→ implementation - Immutable value objects —
RateLimitResult,RateLimiterConfig - Clock injection —
ClockProviderso tests never needThread.sleep
Where concurrency fits
Do not lead with Redis. Lead with: check-and-consume must be atomic for one client; different clients should not block each other. Redis is the answer to shared quota across JVMs, not the first sentence of the interview.