How the interviewer opens it
“Design a central platform that collects and searches logs from thousands of services. Teams need fast searches during incidents and control over how long logs remain available.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Deployment and tenants
- Ingest volume
- Query volume and read:write mix
- Queries and search latency
- Ingest latency and search freshness
- Record format
- Durability, consistency, and availability
- Retention
- Tenant access
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Collect tenant logs from service agents with durable acknowledgments
- Index log text and selected fields
- Search logs by tenant, service, time, severity, and text
- Apply a configurable retention period for each tenant
Usually out of scope
- Metrics and distributed traces
- Alert rules and notifications
- Cross-region disaster recovery
- Automatic removal of secrets from log text
What interviewers ask about
- Log delivery during failures
- The platform must preserve accepted logs while index workers fail. Finite buffers force a clear choice between rejection and data loss.
- Search during incidents
- Incident traffic raises ingest and query demand together. Broad text queries and uneven tenant traffic can consume resources that recent searches need.
- Retention and deletion
- Tenants need different expiry dates on shared storage. Late records, policy changes, and restores can make old logs remain visible.
Common mistakes
- The design treats a successful network send as a durable acknowledgment.
- The design uses the search store as the only buffer during index failures.
- The design creates one index for every service without a shard estimate.
- The design indexes every JSON field and ignores field growth.
- The design gives broad searches unlimited resources during incidents.
- The design defines retention but does not enforce expiry during search or restore.
The bar by level
- Senior (L5/E5)
- Defines durable acknowledgment and replay behavior. Estimates buffer capacity and recovery time. Controls query cost, field growth, tenant load, and retention.
- Staff (L6+/E6+)
- Defines behavior during combined zone loss, backlog, and incident demand. Chooses resource limits and isolation boundaries. Explains recovery, partial results, and storage costs.