System Design Interview
Near real-time analytics that ingests billions of events, aggregates them into time-windowed metrics, and powers live dashboards with sub-minute freshness.
Single service handles ingest, simple rollups, and queries backed by one database.
What was missing: Edge protection, buffering, scalable processors, and OLAP tier.
Why that's risky: SPOF and DB contention; limited throughput and freshness.
What gets added: Nothing yet (MVP).
Trade-offs: Fast to build; not production-ready.
Protect ingress and decouple ingest from processing with a queue.
What was missing: Ingress protection and decoupling from processors.
Why that's risky: Overload propagates to compute and storage.
What gets added: Edge + rate limits + durable queue with optional raw landing.
Trade-offs: Additional infra and ops complexity.
Add stream processor, rollup store, and query API with cache.
What was missing: Scalable processing and fast query path.
Why that's risky: Synchronous compute and DB contention.
What gets added: Stream processor, rollup store, query API, and cache with a dedicated read path from edge.
Trade-offs: Eventual consistency of aggregates.
Harden pipelines with DLQ, late event handling, and backfill workers.
What was missing: Failure isolation and historical correction.
Why that's risky: Poison events and late data skew aggregates.
What gets added: DLQ isolation, replayer workers, and controlled backfill workers for late/corrective processing.
Trade-offs: Higher operational complexity (DLQ workflows, replay safety, and backfill controls).
Add OLAP store/read replicas and region-friendly query performance.
What was missing: Read scale and flexible ad-hoc querying.
Why that's risky: Query hotspots and slow ad-hoc scans.
What gets added: Global CDN, rollup read replica, and OLAP tier for ad-hoc analytics without impacting writes.
Trade-offs: Replica lag and ETL freshness trade-offs must be managed with SLOs.
Add monitoring, lag SLOs, and anomaly detection with alerting.
What was missing: Operational visibility and automated incident response.
Why that's risky: Lag/latency regressions unnoticed; slow manual response.
What gets added: End-to-end monitoring/tracing, anomaly detection, and automated alert notifications.
Trade-offs: Additional cost and potential noisy alerts.
Prefer at-least-once with idempotent processors and de-duplication keys. Exactly-once often adds complexity without clear benefits; track offsets and use transactional writes only where strictly required.
Use event-time processing with watermarks and allowed lateness. Emit corrections to the same aggregate keys; maintain compactable state and a backfill worker to reconcile windows that exceed lateness thresholds.
Front the query API with a cache for hot dashboards, denormalize aggregates for the most common queries, and use replicas for read scaling. Limit query shapes, paginate, and pre-warm caches around known spikes.
Alert on consumer lag, watermark stall, processing error rate, queue depth, and end-to-end freshness. Create SLOs and burn-rate alerts to react before users notice.
Throttle backfills, write to side tables or temp partitions, and validate results before swapping. Use idempotent jobs and pause conflicting online tasks. Monitor impact on primary queues and stores.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
