Problem Statement: A Write-Heavy Behavioral Data Plane
Frames a web analytics tracker as an ingestion-dominated pipeline, not a CRUD application.
Problem statement
Design a Google Analytics-like platform: a JavaScript snippet on millions of third-party websites captures page views and custom events, ships them to a collection tier with negligible page-load cost, and turns the raw clickstream into sessions, funnels, bounce rates, retention cohorts, and real-time dashboards for marketers and product owners.
The defining property of this system is its asymmetry: the write path is enormous, anonymous, lossy-tolerant, and latency-insensitive, while the read path is comparatively tiny but interactive and OLAP-heavy. Public evidence shows the category's scale. W3Techs reports Google Analytics is used by about 48% of all websites and over 83% of sites whose analytics tool is known. Google's own published limits state the free tier stops guaranteeing processing above 10 million hits per month per property, while GA 360 properties may send up to 2 billion hits per month under a 98% processing SLA. Mixpanel's engineering blog says it ingests trillions of data points per month through Apache Kafka, and Amplitude's S-1 discloses roughly 900 billion monthly behavioral data points in mid-2021. These are cited public figures; every uncited number in this answer is an explicit design assumption.
Why this is a distinctive design problem
- The client is untrusted, adversarial, and constrained: ad blockers (used by roughly 30% of internet users per GWI data), browser tracking prevention, and slow phones all attack the write path. The snippet must be tiny, async, and batched, and the architecture must assume 25-40% of human traffic is partially invisible.
- Identity is fuzzy: cookies expire, browsers partition them, visitors switch devices. Sessions and uniques are statistical constructs, not facts. GA4 itself estimates Active Users with HyperLogLog++ rather than exact counting.
- Accuracy is a budget, not a guarantee: GA samples above 10 million events per query; the design must choose between exact, sampled, and sketched answers per report type.
- Privacy is architecture: the 2022 CNIL ruling that Google Analytics transfers violated GDPR Article 44 turned collection topology (where IPs and identifiers land) into a legal constraint, not a preference.
The four planes of the design
- Collection plane: snippet, beacon transport, edge collectors, validation, consent gating.
- Identity plane: cookie and client-ID management, sessionization, cross-device stitching, bot filtering.
- Processing plane: durable stream, stream sessionization, rollups, sketches, batch archive, OLAP store.
- Activation plane: reporting APIs, dashboards, segmentation, funnels, exports, alerting.
A strong interview answer keeps these planes separate, states which data may be lost (routine page views under overload) versus which must not (billing-relevant metering, consent records), and quantifies the write/read asymmetry before drawing boxes.
Key Highlights
- •Write-heavy asymmetry: billions of tiny events in, tens of OLAP queries out; the two paths scale differently.
- •Public scale anchors: GA on ~48% of all websites; GA 360 up to 2B hits/month; Mixpanel trillions of events/month via Kafka.
- •Uniques and sessions are estimates: GA4 uses HyperLogLog++ for Active Users; sampling kicks in above 10M events.
- •Ad blockers and tracking prevention make the write path lossy by design; plan for 25-40% partial invisibility.
- •Privacy is topology: CNIL's 2022 ruling made collector geography and identifier handling legal requirements.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate the lossy behavioral write path from the small number of datasets that must never lose data."
- "Before drawing services, I want to quantify events per second versus queries per second, because they scale independently."