1 min lesson
Mock system-design: Cursor's data platform v1
Rebuild the parts of "Mock system-design: Cursor's data platform v1", then say why each one matters.
Step 1 of 3
Set a 50-minute timer and a whiteboard. The prompt: design ingestion → lakehouse → orchestration → serving for billions of Cursor events per day, plus third-party business data, on a platform that barely exists yet. That last clause is the whole role. You are not running someone's mature stack; you are drawing the first version.
The deep-dive round watches one thing above raw architecture: do you reason like the person who will own this at 3am when freshness alerts fire. Quantify before you draw, name the failure modes before someone asks and kill your own components when the tail gets expensive.
Learn more
Full explanation
Walk the four layers in order
Walk the four layers in orderIngestion → lakehouse → orchestration → serving
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
Step through it in order; the gates are the steps generic candidates skip.
The figure's nodes cover ingestion through serving; orchestration is the layer that ties them together and doesn't get its own box. Model tables as Dagster software-defined assets so lineage is the graph, not a wiki. Partition assets by date to make backfills and replays a first-class operation, not a panicked manual script. Use sensors to trigger off Kafka offsets or file arrival instead of blind cron where freshness matters.
Learn more
Advanced table
Name the failure modes before you're asked
Name the failure modes before you're askedThis is where most candidates thin out
- Failure mode
- Duplicate events on retry
- Design answer
- At-least-once delivery + idempotent MERGE on a stable event key; treat exactly-once as a cost trade, not a default
- Failure mode
- Producer ships a breaking schema
- Design answer
- Schema registry rejects at the edge; bad records to dead-letter with offset + reason so you can replay after a fix
- Failure mode
- Late-arriving data
- Design answer
- Event-time partitioning + watermark window; reprocess the affected date partition rather than the whole table
- Failure mode
- Small-file explosion
- Design answer
- Buffer to sane batch sizes, compact on a schedule, monitor file count per partition as an SLO
- Failure mode
- Silent freshness lag
- Design answer
- Freshness check per gold asset with an SLA; page on the asset, not on the cluster
| Failure mode | Design answer |
|---|---|
| Duplicate events on retry | At-least-once delivery + idempotent MERGE on a stable event key; treat exactly-once as a cost trade, not a default |
| Producer ships a breaking schema | Schema registry rejects at the edge; bad records to dead-letter with offset + reason so you can replay after a fix |
| Late-arriving data | Event-time partitioning + watermark window; reprocess the affected date partition rather than the whole table |
| Small-file explosion | Buffer to sane batch sizes, compact on a schedule, monitor file count per partition as an SLO |
| Silent freshness lag | Freshness check per gold asset with an SLA; page on the asset, not on the cluster |
Each row is a question you answer before the interviewer reaches for it.