Microsoft·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

May 2026

Summary

Microsoft system design round for a software engineering role. The whole session was basically one deep problem about rate limiting, which sounds contained until you realize how many directions they can pull it.

Questions Asked (1)

Design a Logger class that suppresses duplicate or too-frequent messages within a configurable time window. Define the API, the data structures, thread safety, memory cleanup, and how you'd extend it to support more advanced rate limiting strategies.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I started with the obvious hashmap approach, message to last-printed timestamp, and they seemed fine with that.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (e.g., what constitutes a duplicate, time window semantics, thread safety needs) and then present a clean API with a hash map keyed by message to track last-seen timestamps. Discuss thread safety via locking or concurrent data structures, memory cleanup with periodic eviction or TTL, and outline extensions like token bucket or sliding window for advanced rate limiting.

Pro tip: Emphasize the trade-off between precision and memory: using a fixed-size LRU cache or approximate data structures like count-min sketch can bound memory while still effectively suppressing duplicates, which is often more practical than exact tracking at scale.

1. Clarify Requirements and Scope

Ask questions to pin down the definition of duplicate (exact match vs. normalized), the time window behavior (sliding vs. fixed), expected throughput, and whether thread safety is required. This shows you avoid assumptions and design for the actual use case.

2. Define the API and Core Data Structures

Propose a simple API like log(message) and a hash map from message to last timestamp, plus a queue or timing wheel for efficient eviction. Explain how the time window is enforced by comparing current time with stored timestamps.

3. Address Thread Safety and Concurrency

Discuss options: coarse-grained locking (simple but contended), fine-grained locking per bucket, or lock-free structures like ConcurrentHashMap with atomic updates. Mention the trade-offs between correctness, performance, and complexity.

4. Handle Memory Cleanup and Eviction

Describe strategies: periodic background thread to remove expired entries, lazy eviction on access, or using a bounded cache with LRU eviction. Highlight the need to avoid unbounded growth and the impact on accuracy.

5. Extend to Advanced Rate Limiting

Outline how to evolve the design to support token bucket, leaky bucket, or sliding window counters. Explain how to parameterize limits per message or globally, and mention distributed rate limiting considerations if relevant.

Key Points to Mention

Time window semantics: sliding vs. fixed, and how to handle boundary conditions.
Thread safety mechanisms: locks, concurrent collections, and atomic operations.
Memory management: eviction policies (TTL, LRU) and bounded data structures.
Trade-offs between exactness and scalability (e.g., approximate counting).
Extensibility: strategy pattern for pluggable rate limiting algorithms.
Performance considerations: lock contention, cache locality, and throughput.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.