Logger Rate Limiter

Logger Rate Limiter

What is this problem about?

The Logger Rate Limiter interview question asks you to design a system that manages the printing of log messages over time. Specifically, you need to implement a class or data structure that receives a continuous stream of messages along with their timestamps. The system must decide whether to print a given message or drop it, based on a rate-limiting rule: a message should only be printed if it has not been printed in the last X seconds (usually 10 seconds). It tests your ability to handle a data stream and manage state efficiently.

Why is this asked in interviews?

Companies love this design problem because it mimics real-world scenarios. In production systems, an error might trigger a flood of identical log messages, filling up storage and making debugging impossible. A rate limiter prevents this spam. Interviewers use this question to assess your grasp of basic system design, state management, and your ability to choose the right data structure for fast lookups. It is highly practical and often serves as a warm-up for more complex distributed systems questions.

Algorithmic pattern used

The optimal approach utilizes the Hash Table (or Dictionary) pattern. Since the system receives a data stream and needs to perform an immediate lookup to check the history of a specific message, a hash table provides constant O(1) average time complexity for both insertions and lookups. The keys in the hash table represent the unique log messages, and the values store the timestamp of when that message is next allowed to be printed.

Example explanation

Imagine the rule is to limit identical messages to once every 10 seconds.

• At time = 1, the message "error" arrives. It hasn't been seen before, so we print it and record that "error" cannot be printed again until time = 11.
• At time = 3, the message "warning" arrives. It's new, so we print it. Next allowed time is 13.
• At time = 8, another "error" message arrives. We check our history: "error" is blocked until 11. Since 8 < 11, we drop this message.
• At time = 12, an "error" message arrives again. Now, 12 >= 11, so we print it and update the next allowed time for "error" to 22.

Common mistakes candidates make

A frequent pitfall is over-engineering the solution. Candidates sometimes try to maintain a queue or an array of all timestamps for every message, and then run cleanup jobs to remove old entries. While keeping memory bound is a valid concern in large-scale systems, for the basic version of this Logger Rate Limiter coding problem, a simple dictionary mapping a string to its latest expiration integer is sufficient and keeps code clean and bug-free.

Interview preparation tip

When preparing for the Logger Rate Limiter interview pattern, practice implementing the solution cleanly using a hash map. Also, be ready to discuss trade-offs: what happens if the system runs for years and the hash map grows indefinitely? You should be prepared to explain how you might implement a cleanup mechanism (like a background thread or an ordered dictionary based on time) if the interviewer pushes for memory constraints.