From single machine to distributed
Production rate limiters (API gateways, mesh, Redis sliding windows) add shared state and clock skew. Before that complexity, you should be fluent with the in-process versions:
- Logger Rate Limiter — "should this message print?" per message key within 10s.
- Design Hit Counter — sliding window of hits in the past 5 minutes (timestamp queue or bucket array).
Idempotency is the other half: at-least-once delivery (Topic 8) is harmless only if handlers deduplicate on an idempotency key. The dedup-store task simulates what every payment webhook implements.
Senior signal
In a design round: "We accept at-least-once from Kafka; the consumer stores processed offsets and idempotency keys in a store with TTL ≥ max redelivery window."
In coding: implement the store first; distributed Redis is "same API, networked."
Practice order
- LeetCode Logger Rate Limiter (warm-up).
- LeetCode Design Hit Counter (sliding window).
- Code
IdempotencyStorewith injectable clock and unit tests.
Further Reading
Coding Exercises (Optional)
In-memory specs — implement locally with unit tests. No cluster, Docker, or cloud setup unless a task says otherwise.
- Code: Idempotency dedup store (TTL)30m
Implement `IdempotencyStore` with `record(key, ttl_seconds)` and `seen(key) -> bool`. After `record`, `seen` returns true until ttl expires (use a monotonic clock or inject `now()` for tests). Reject duplicate keys within the window; allow reuse after expiry. Simulate a payment webhook handler: first delivery processes; retry with same `Idempotency-Key` within 24h is a no-op; after TTL, same key may be accepted again. Unit-test with a fake clock. ~30 minutes.
Autograded Problems (Optional)
External judges (LeetCode). Same distributed concepts — solve in your editor, submit on the platform.
- Logger Rate LimiterEasy2/520m
- Design Hit CounterMedium3/530m