Problem Statement: Behavioral Truth at Write-Heavy Scale
Frames the tool as a write-dominated behavioral data platform, not a dashboard over a conventional OLTP database.
Problem statement
Design a session analysis and heatmap platform that records user interactions on customer websites - cursor moves, clicks, scrolls, pageviews, DOM mutations - stores sessions durably, replays them faithfully, and aggregates them into heatmaps and funnel analyses that designers and product managers can query in near real time.
The defining property of this system is its asymmetry: it is brutally write-heavy on the ingest side (hundreds of thousands of small events per second from millions of browser sessions) and comparatively read-light but latency-sensitive on the analyst side (a heatmap tile must render in under a second while it aggregates millions of points). Most candidates design the read path well and the write path badly. The interview is won on the write path: sampling, batching, compression, backpressure, quotas, and privacy masking before a single byte leaves the browser.
Why this is distinctive
A session replay tool is three products sharing one pipeline: (1) a capture SDK that must be tiny, safe, and privacy-correct inside untrusted customer pages; (2) an ingestion and storage engine that must absorb tens of billions of events per day cheaply; (3) an analysis engine that must turn raw coordinates into heatmaps, scroll maps, and funnels with honest statistics. The capture format determines everything downstream: DOM-mutation event sourcing (the rrweb approach) yields compact, faithful replay, while screenshot video yields fidelity at 10-100x the bytes and loses element semantics needed for heatmaps.
Public operating baseline versus design assumptions
Public evidence shows the category is real and large. Hotjar, now part of Contentsquare, ships heatmaps and session replay with a free tier of 200k sessions per month and autocapture [[43]]. FullStory publicly describes building its Digital Experience Intelligence platform for scalability and reliability on Google Cloud [[18]]. OpenReplay publishes an open-source stack of Go services, Kafka, and ClickHouse for session replay [[34]]. rrweb is the de-facto open capture standard, recording DOM snapshots plus incremental mutations and deflate-compressing them with its packer [[36]]. Sentry runs rrweb-based replay and cut its SDK bundle 35% by compressing in a web worker [[38]]. These are cited public facts; every uncited number in this answer is an explicit design assumption.
The four planes
- Capture plane: in-browser SDK - consent gating, PII masking, sampling, delta encoding, batching, retry.
- Ingest plane: edge collectors, auth and quotas, durable streams, schema validation, dedupe.
- Analysis plane: stream and batch aggregation - heatmap grids, scroll depth, funnel counts, sessionization.
- Consumption plane: tile server, replay player API, search, dashboards, exports, privacy enforcement on read.
A strong answer keeps the planes separate, makes masking happen at plane 1 (you cannot unsend PII), and treats every aggregate as recomputable from the durable raw stream.
Key Highlights
- •Write-heavy asymmetry: ingest is the hard path; analyst reads are few but latency-sensitive.
- •Capture format is the root decision: DOM-mutation event sourcing beats screenshot video for cost and element semantics.
- •PII masking must occur client-side before transmission; server-side masking is a second layer, not the first.
- •Four planes: capture, ingest, analysis, consumption - each with different consistency and latency needs.
- •Every heatmap and funnel is a recomputable projection over a durable, replayable raw event stream.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate capture, ingest, analysis, and consumption before choosing any technology."
- "The first design constraint is privacy: what may leave the browser at all, and at what precision."