Cursor·Backend Engineer·Onsite - System Design / Architecture
- Design a production-grade rate limiter for notification sending that enforces per-user, per-team, and per-company limits simultaneously within an exact rolling 10-minute window. A send is only accepted if all three limits pass, and a rejection must not count against any scope.
- How do you keep the user, team, and company rate limit checks atomic across concurrent requests from many stateless servers?
- What clarifying questions would you ask before designing this system?
- How do you handle the user-to-team-to-company mapping, and what happens when a user is transferred to a different team mid-operation?
- If the limits were changed from 3/10/20 to thousands per window, would you still use an exact sliding window log, and what would you switch to if not?
- One large company's traffic is making its shard a bottleneck. How do you relieve the hot shard while still enforcing the exact company-level limit?
- Walk through what happens end-to-end when the Redis cluster is briefly unavailable. What does your service return, what gets logged, and how do counts reconcile when it comes back?
- How would you add a fourth rate limiting scope, like a per-notification-channel limit, without rewriting the atomic core of the system?
“This was the core question and it ate most of the session.”