Discuss productionizing event-timeout detector

Read the full interview experience this question came from →

Quick Overview

Discuss productionizing event-timeout detector 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.

Discuss productionizing event-timeout detector

Company: Applied Intuition

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Define and evaluate a production-ready architecture for the event-timeout detector. Specify the external API and data model (schemas, idempotency keys), time semantics (processing vs event time), and handling of clock skew. Describe sharding strategy by event_id, state storage choice, consistency model for reads, and failure recovery. Discuss performance optimizations (e.g., timer wheels vs heaps/LRU, batching), backpressure, and memory limits. Enumerate production edge cases (late/dropped/duplicated/reordered messages, very large timeouts, long silences, restarts) and how you would test, monitor, and alert.

Overview: Discuss productionizing event-timeout detector 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 Applied Intuition Software Engineer interview experience this question came from

|Home/Applied Intuition/System Design
Applied Intuition logo
Applied Intuition
Jul 17, 2025
hardSoftware EngineerTechnical ScreenSystem Design
20
0

Discuss productionizing event-timeout detector

System Design: Production-Ready Event-Timeout Detector

You are designing a production service that detects when an event fails to occur within a specified duration (a timeout). For example, after a Start event for event_id=X, if a matching Stop or Heartbeat does not arrive within T, emit a Timeout for X.

Define and evaluate a production-ready architecture that addresses the following:

External API and Data Model

  • Specify request/response APIs to:
    1. Create/schedule a timeout for an event_id
    2. Cancel or complete the event
    3. Extend or heartbeat the timeout
    4. Query the current status
    5. Receive timeout notifications (push or pull)
  • Provide data schemas, including idempotency keys and dedup strategy.

Time Semantics and Clock Skew

  • Define whether timeouts are evaluated in event time or processing time, and the rationale.
  • Describe watermarking/allowed lateness if you choose event time.
  • Explain how to handle client/server clock skew, including guardrails.

Partitioning, State, Consistency, Recovery

  • Sharding strategy by event_id, partition ownership, and rebalancing.
  • State storage choice (in-memory vs local persistent vs remote KV) and what is stored.
  • Consistency model for reads (linearizable vs eventual) and for emitted timeouts.
  • Failure recovery: restarts, replays, snapshots, and exactly-once/at-least-once guarantees.

Performance and Resilience

  • Data structures for timers (timer wheels vs min-heap vs multi-level wheels), batching, and LRU/near-term caching.
  • Backpressure strategy across API and ingestion pipeline.
  • Memory limits and spill-to-disk strategy.

Production Edge Cases

  • Late, dropped, duplicated, and reordered messages
  • Very large timeouts (hours/days), long silences/inactivity
  • Service restarts and partition moves
  • Idempotency and side-effect delivery (e.g., notifications)

Testing, Monitoring, and Alerting

  • How you would test (unit, property, integration, chaos, load/soak) and what to validate.
  • Key metrics, logs, traces, dashboards, and alert thresholds.

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?

Browse More Questions

More System Design•More Applied Intuition•More Software Engineer•Applied Intuition Software Engineer•Applied Intuition System Design•Software Engineer System Design