2 min lesson
Schema registry and evolution
Respond to "Why is 'at-least-once delivery plus idempotent writes' usually the right default for high-volume telemetry and what makes it work?" Name the reason and the detail behind it.
Step 1 of 3
Schema registry and evolutionkeep producers and the lakehouse from breaking each other
Hundreds of client builds emit events independently, so a producer will add a field or change a type without warning. A schema registry gives every event type a versioned schema and enforces compatibility rules at publish time, so a breaking change is rejected at the producer instead of corrupting bronze.
- Backward compatibility lets new consumers read old data - add optional fields, never repurpose an existing one.
- Forward compatibility lets old consumers tolerate new data - they ignore unknown fields rather than crash.
- Bronze stays permissive, silver stays strict. Land what arrives, then enforce the contract on the way to silver so a producer hiccup degrades one table, not the platform.
Backpressure, dead-letter queues and replay are not optional at billions a day - they're the difference between a bad hour and a bad week. A poison message with no dead-letter path stalls the whole consumer group; no backpressure and a producer spike overruns your buffer and you drop data silently. Always say where malformed events go and how you replay them.
If asked "exactly-once or at-least-once," don't pick a side abstractly. Say: "At-least-once with idempotent writes for the telemetry firehose, because dups are cheap to collapse on a stable event key and the coordination cost of true exactly-once isn't worth it at this volume. I'd reserve stronger semantics for flows like billing where a duplicate is a real error." Tying the choice to the specific flow is the senior answer.
Learn more
Optional practice