This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design log management with auto-deletion states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design a log management system that
(
1) keeps the total number of logs ≤ total_max,
(
2) automatically deletes the least important or oldest logs when adding new ones to stay within limits, and
(
3) locates logs to delete in O(
1) time using appropriate data structures (e.g., time-ordered deque plus priority heap).
Overview: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design log management with auto-deletion states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Design a Bounded Log Management System with O(1) Victim Selection
Context
You are designing an in-memory log buffer that ingests log entries and must never exceed a configured capacity (total_max). Each log has:
id (unique)
timestamp (arrival time; assume non-decreasing or we treat arrival time separately from event time)
importance (integer; lower means less important)
payload (opaque)
When the buffer is full and a new log arrives, the system should automatically evict logs to stay within capacity, preferring to remove the least important logs; ties are broken by oldest timestamp.
Requirements
Maintain total number of logs ≤ total_max at all times.
On insert, automatically delete logs to make room, preferring:
Lowest importance first, and if there’s a tie,
Oldest by arrival timestamp.
Locate the next log to delete in O(1) time (e.g., via a time-ordered deque and a min-priority heap). Overall update/eviction cost can exceed O(1) due to necessary re-indexing.
Deliverables
Describe the core data structures and how they interact.
Specify insertion and eviction algorithms and their time/memory complexity.
Include assumptions, tie-breaking rules, and handling of out-of-order timestamps.
Provide concise pseudocode for key operations.
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?