Rate Limiter Function and Distributed Design

Start with a small `shouldPass` rate-limiter function, then discuss how the same limiter works across API gateways or services. Follow-ups focus on rejected requests, per-customer or per-IP limits, memory growth, Redis/cache choices, consistency, and scaling. Requirements Implement a function like boolean shouldPass(int timeBucket) for a rate limit. Generalize to at most y accepted requests in x buckets or a sliding window. Clarify whether rejected requests count toward future limiting decisions. Discuss memory growth when request volume is high; candidates were expected to notice list-based storage issues. Follow-ups include per-customer or per-IP accounting and a system-design version used by many services or API gateways. Notes For the distributed design, key decisions include Redis or another fast shared store, sharding, consistency between gateways, and whether counters need long-term durability. Interviewers may ask about optimistic vs pessimistic concurrency control if the design uses SQL or DynamoDB-style storage. Preparation Code fixed-window, sliding-window-log, and token-bucket variants. Practice explaining the storage trade-off between exact logs, rolling counters, and approximate counters under high traffic.