Design a prioritized log manager with eviction evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Design a log management component that supports prioritized deletion under capacity constraints. Requirements:
(
1) The total number of stored log records across all files must not exceed total_max.
(
2) addLog(fileId, record, priority, timestamp) must automatically evict old data when limits are exceeded.
(
3) When eviction is required, delete the "least important" logs first according to a well-defined policy that considers priority (higher is more important) and recency (newer is more important).
(
4) Support both per-file limits (optional X per file) and a global limit total_max.
(
5) Provide APIs to add logs, query by file, and observe current capacities. Target complexities: O(
1) or amortized O(
1) to identify a deletion candidate and O(log n) or better per insertion/eviction. Describe your data model, data structures, and trade-offs.
Quick Answer: Design a prioritized log manager with eviction evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Design a Log Store with Priority- and Recency-Aware Eviction
Context
You are designing an in-memory (or on-disk) log storage component. Each inserted log belongs to a file (fileId) and has a priority and a timestamp. Storage is bounded by a global capacity and optional per-file capacities. When capacity is exceeded, the system must automatically evict the "least important" logs first. Importance is defined by priority (higher = more important) and recency (newer = more important).
Requirements
Global capacity: The total number of stored log records across all files must not exceed
total_max
.
Automatic eviction:
addLog(fileId, record, priority, timestamp)
must automatically evict when limits are exceeded.
Eviction policy: When eviction is required, delete the least important records first. Importance considers:
Priority (higher is more important), and
Recency (newer is more important).
Limits: Support both per-file limits (optional
limit[fileId] = X
) and a global limit
total_max
.
APIs and complexity targets:
Provide APIs to add logs, query by file, and observe capacities.
Target complexities: O(1) (or amortized O(1)) to identify a deletion candidate and O(log n) or better per insertion/eviction.
Deliverable
Describe your data model, data structures, eviction policy, algorithms, and trade-offs that meet the above requirements and complexities.
Constraints & Assumptions
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
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?