Design a Real-Time Gaming Stream Metrics Aggregator
We want to build a platform that ingests high-volume telemetry events from live video game matches and computes real-time performance analytics for players and teams. Your system needs to accept these raw event streams, process them continuously, and serve live aggregated leaderboards and summaries.
This brief is incomplete on purpose, as it would be in a real interview. Ask the interviewer about the users, the features, the targets and the traffic — whatever you uncover is added below.
- The system must ingest raw player telemetry event streams from connected gaming clients and game servers.
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- Not uncovered yet
- The high-level architecture diagram showing ingestion, stream processing, and storage tiers
- The data flow and state management strategy for windowed aggregations
- The storage and database selection for real-time leaderboards versus historical archives
- The strategy for handling traffic spikes and backpressure during tournament peaks
Shows a scalable distributed message broker or ingestion buffer capable of absorbing high-throughput streaming telemetry without dropping events during bursts.
Demonstrates a clear stream processing topology that handles stateful rolling aggregations and window calculations accurately under high event volumes.
Selects appropriate storage engines for real-time low-latency reads versus long-term historical cold storage, explaining trade-offs in consistency and query performance.
Accurately converts monthly totals and peak ratios into peak throughput rates, using those figures to size the ingestion and compute layers.
Addresses how the pipeline handles upstream telemetry floods, network partitions, and downstream consumer lag without systemic failure.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Do not write any code, function signatures, or language-specific implementations. Concentrate on the overall architecture, data flow, storage choices, and scalability trade-offs on the whiteboard.
- Views
- 1