Skip to main content
Talentd

Logger Rate Limiter - Solution & Explanation

EasyPremiumFree on FleetCodeHash TableDesignData Stream7 min readAsked at: Amazon, Microsoft, Apple +18
Practice this problem

Problem Statement

Design a logger system that receives a stream of messages along with their timestamps. Each unique message should only be printed at most every 10 seconds (i.e. a message printed at timestamp t will prevent other identical messages from being printed until timestamp t + 10).

All messages will come in chronological order. Several messages may arrive at the same timestamp.

Implement the Logger class:

  • Logger() Initializes the logger object.
  • bool shouldPrintMessage(int timestamp, string message) Returns true if the message should be printed in the given timestamp, otherwise returns false.

 

Example 1:

Input
["Logger", "shouldPrintMessage", "shouldPrintMessage", "shouldPrintMessage", "shouldPrintMessage", "shouldPrintMessage", "shouldPrintMessage"]
[[], [1, "foo"], [2, "bar"], [3, "foo"], [8, "bar"], [10, "foo"], [11, "foo"]]
Output
[null, true, true, false, false, false, true]

Explanation
Logger logger = new Logger();
logger.shouldPrintMessage(1, "foo");  // return true, next allowed timestamp for "foo" is 1 + 10 = 11
logger.shouldPrintMessage(2, "bar");  // return true, next allowed timestamp for "bar" is 2 + 10 = 12
logger.shouldPrintMessage(3, "foo");  // 3 < 11, return false
logger.shouldPrintMessage(8, "bar");  // 8 < 12, return false
logger.shouldPrintMessage(10, "foo"); // 10 < 11, return false
logger.shouldPrintMessage(11, "foo"); // 11 >= 11, return true, next allowed timestamp for "foo" is 11 + 10 = 21

 

Constraints:

  • 0 <= timestamp <= 109
  • Every timestamp will be passed in non-decreasing order (chronological order).
  • 1 <= message.length <= 30
  • At most 104 calls will be made to shouldPrintMessage.

Approach Overview

Problem Overview: You need to design a logger system that decides whether a message should be printed at a given timestamp. Each message can only be printed once every 10 seconds. If the same message appears again within that window, the logger must suppress it.

Approach 1: Brute Force Log Scan (O(n) time, O(n) space)

Store every printed message with its timestamp in a list or queue. When a new request arrives, iterate through the stored logs to find the most recent occurrence of that message. If the difference between the current timestamp and the stored timestamp is at least 10 seconds, allow printing; otherwise reject it. This approach works but becomes inefficient as the log grows because every query may require scanning multiple entries. The time complexity per request can degrade to O(n), while space complexity is also O(n) for storing past messages.

Approach 2: Hash Table with Last Printed Timestamp (O(1) time, O(n) space)

Use a hash table that maps each message string to the last timestamp when it was printed. For every incoming message, perform a constant-time lookup in the map. If the message is not present, or if currentTimestamp - lastTimestamp >= 10, update the stored timestamp and return true. Otherwise return false. Hash lookups and updates run in O(1) average time, making this approach extremely efficient for continuous streams of log events.

This technique fits naturally with design problems where the system must respond quickly to frequent queries. Since messages arrive in chronological order (a typical assumption in data stream problems), the stored timestamps remain valid without extra cleanup logic. The space usage grows with the number of unique messages and is O(n).

Recommended for interviews: The hash table approach is the expected solution. It demonstrates the ability to convert repeated lookups into constant-time operations using a map. Mentioning the brute force scan shows you understand the baseline, but implementing the hash map version shows strong problem-solving and system design instincts.

Solution

We use a hash table ts to store the next available print timestamp for each message. When the shouldPrintMessage method is called, we check whether the current timestamp is greater than or equal to the next available print timestamp for the message. If so, we update the next available print timestamp to the current timestamp plus 10 and return true; otherwise, we return false.

The time complexity is O(1). The space complexity is O(m), where m is the number of distinct messages.

Code

PythonJavaC++GoJavaScript

Python

Java

C++

Go

JavaScript

Try this approach in the editor →

Detailed Complexity Analysis

ApproachTimeSpaceWhen to Use
Brute Force Log ScanO(n) per requestO(n)Conceptual baseline or very small log sizes
Hash Table (Last Timestamp)O(1) averageO(n)Best choice for real-time logging systems and interview solutions

Video Solution

LOGGER RATE LIMITER | LEETCODE # 359 | PYTHON SOLUTION • Cracking FAANG • 11,391 views views

Watch 9 more video solutions →

Frequently Asked Questions

Is Logger Rate Limiter easy or hard?
Logger Rate Limiter is classified as an Easy problem on LeetCode. The core idea is straightforward once you recognize that storing the last timestamp in a hash map allows constant-time decisions for each message.
Logger Rate Limiter Python/Java solution
The standard implementation uses a dictionary in Python or a HashMap in Java to track the last printed timestamp for each message. Each call checks the stored timestamp and updates it if the message can be printed.
How to solve Logger Rate Limiter in O(1)?
Maintain a hash map where the key is the message and the value is the last printed timestamp. For each new request, look up the message and check if currentTimestamp minus storedTimestamp is at least 10. If true, update the timestamp and return true; otherwise return false.
What is the best approach for Logger Rate Limiter?
The most efficient approach uses a hash table that maps each message to the last timestamp when it was printed. When a new message arrives, check the stored timestamp and allow printing only if at least 10 seconds have passed. This gives O(1) average time per request and O(n) space for storing unique messages.
Is Logger Rate Limiter asked at Google/Amazon/Meta?
Logger Rate Limiter is a common design-style interview problem seen at companies like Google, Amazon, and Meta. It tests understanding of hash tables, efficient lookups, and basic system design concepts for handling streaming data.
What data structure is used in Logger Rate Limiter?
A hash table (hash map) is the primary data structure used. It stores each message string as a key and the last printed timestamp as the value, enabling constant-time checks and updates.
What is the time complexity of Logger Rate Limiter?
Using the optimal hash table design, each logger check runs in O(1) average time because message lookups and updates are constant-time hash operations. Space complexity is O(n), where n is the number of unique messages stored in the logger.

Ready to solve this problem?

Practice Logger Rate Limiter with our built-in code editor and test cases.

Practice on FleetCode
Previous

Design Hit Counter