Design a prioritized log manager with eviction

Read the full interview experience this question came from →

Quick Overview

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 prioritized log manager with eviction

Company: Google

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

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.

Overview: 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.

Read the full Google Software Engineer interview experience this question came from

|Home/System Design/Google
Google logo
Google
Aug 1, 2025
hardSoftware EngineerTechnical ScreenSystem Design
9
0

Design a prioritized log manager with eviction

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

  1. Global capacity: The total number of stored log records across all files must not exceed total_max .
  2. Automatic eviction: addLog(fileId, record, priority, timestamp) must automatically evict when limits are exceeded.
  3. 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).
  4. Limits: Support both per-file limits (optional limit[fileId] = X ) and a global limit total_max .
  5. 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.

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?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...