How the interviewer opens it
“Design a web analytics platform like Google Analytics. Websites send page views and other events, and site owners use dashboards to understand users, sessions, and funnels.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- scale
- payload and read:write mix
- dashboard and funnel scope
- users and sessions
- latency
- consistency and delivery
- event time and lateness
- retention and durability
- privacy and access
- out of scope
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Collect page views and custom events through a browser SDK.
- Calculate per-site users, sessions, and configured ordered funnels.
- Serve dashboards with date ranges and standard breakdowns.
- Authenticate site owners and isolate each site's data and workload.
Usually out of scope
- Advertising attribution and campaign bidding.
- Cross-site or cross-device identity resolution.
- Arbitrary SQL over raw events.
- Building bot detection or fraud detection.
- Multi-region disaster recovery and full regulatory deletion workflows.
What interviewers probe
- Retry-safe collection and processing
- Browsers retry after ambiguous failures, and stream workers replay after crashes. At this volume, duplicate suppression is substantial state, while acknowledging too early can lose events that the service promised to keep.
- Event-time sessions and late corrections
- A session is not just a fixed time bucket. A late event can bridge two sessions, changing session totals, entry dimensions, and funnel conversion after those results have already appeared.
- Distinct users and ordered funnel queries
- Daily user counts cannot simply be added, and a funnel is an ordered sequence within the same session—not independent totals for its steps. Long-range reports must avoid repeated scans of billions of events.
- Tenant skew and uncontrolled cardinality
- A million websites are not a million equal workloads. One site can dominate ingestion, while arbitrary URLs and event names can explode aggregate state and query cost even without increasing event volume.
Common mistakes
- Treating accepted events as ordinary transactional rows and running all dashboards against the ingestion database.
- Ignoring duplicate delivery or assuming a queue's delivery guarantees automatically extend to analytics-store writes.
- Using processing time or fixed time buckets for sessions and ignoring late-event merges.
- Adding distinct-user estimates across dates or calculating funnels from unrelated aggregate event counts.
- Promising arbitrary 90-day raw-event analysis while retaining raw events for only 30 days.
- Ignoring tenant skew and dimension cardinality, leading to hot partitions or unbounded aggregation state.
The bar by level
- Senior (L5/E5)
- Quantifies ingestion, retention, and deduplication state; makes acknowledgment and sink replay behavior explicit. Handles event-time session merges with provisional results and corrections, ordered per-session funnels, mergeable distinct counts, and supported rollups. Addresses hot tenants, cardinality limits, and the 30-day raw versus 90-day derived-data boundary.
- Staff (L6+/E6+)
- Defines the exact observable metric semantics and failure boundaries, including what is provisional, final, approximate, or unrecoverable. Chooses a bounded-state design with an operationally credible replay and correction path, explains aggregate replacement and sketch limitations, and balances tenant isolation against shared capacity cost. Adapts honestly to historical redefinition, deletion, or regional failover without claiming guarantees that browser identity or retained data cannot support.