1 min lesson
Mini system-design: product telemetry ingestion
Use "Mini system-design: product telemetry ingestion" to explain each part and the role it plays.
Step 1 of 2
This is the design round in miniature: take Cursor's editor telemetry from the client to feature tables and narrate the trade-off at every hop. The structure below is one you can reuse cold.
Open by restating requirements before you draw anything - it's the move that separates a structured answer from a brain-dump.
- Volume
- Billions of Cursor client/editor events per day; size for the working-hours peak
- Loss tolerance
- Low - telemetry feeds product metrics and agent training, so dropped events skew both
- Replayability
- Must be able to reprocess from raw after a bug fix or schema change
- Latency
- Minutes to bronze is fine; sub-second isn't the goal for analytics/training
- Cost
- Bounded - the layout has to keep storage and read cost sane at this volume
Learn more
Full explanation
The pipeline, hop by hop
The pipeline, hop by hopclient to feature tables
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
The two gates are where bad data is stopped: idempotency on the way into bronze, schema enforcement on the way into silver.
The figure carries the hops; your job in the room is to narrate the same four concerns at each one - partitioning, compaction, schema evolution and dead-letter handling. Saying "malformed events go to a dead-letter topic with the raw payload and error and I can replay them after a fix" is worth more than any extra box on the diagram.
Learn more
Optional practice
Practice: Mini system-design: product telemetry ingestion
QIn your telemetry design, why is Kafka (the stream) placed between the ingest gateway and bronze rather than writing events straight to Delta?