Preparing chapter
Loading your data design lesson
The curriculum shell is ready while the requested chapter is being prepared. You can wait here or return to the design library.
Preparing chapter
The curriculum shell is ready while the requested chapter is being prepared. You can wait here or return to the design library.
BookMyShow · Data Engineering · Facts that survive change
Design envelopes, ordering keys, retention, and evolution rules for durable facts.
Event envelope in the pipeline
The envelope is the common wrapper around seat-held, booking-confirmed, payment, catalog, and client events. The payload contains the event-specific fact.
Where the envelope fits
Identity, type, version, ordering, timestamps, producer, and trace information.
For example: booking, show, seats, price, currency, and payment reference.
{
}SELECTED FIELD 01
Gives one business fact a stable identity across CDC and producer retries.
BOOKMYSHOW EXAMPLE
The booking-confirmed event keeps event_id e_01J... even if Debezium publishes it again.
WHO USES IT
Flink, Spark, and serving sinks use it to ignore duplicate copies of that event.
Canonical event contracts
Choose an event to see its Kafka route, key, business rules, ordering promise, and a complete envelope-plus-payload record.
A complete seat basket was atomically reserved for one temporary hold.
TOPIC
inventory.events
KEY
show_id
OWNER
Inventory service
DELIVERY PATH
Postgres outbox → Debezium → Kafka
PAYLOAD FIELDS
MUST ALWAYS BE TRUE
Publish only after every requested seat is owned by the same hold. A partial A7/A8 hold is invalid.
ORDERING PROMISE
Key by show_id when all conflicting seat transitions for a show must remain in one ordered Kafka partition.
COMPACT COMPLETE BUSINESS RECORD
Essential envelope + all required payload fields
{
"event_id": "e_hold_01J9",
"event_type": "inventory.seat_held",
"schema_version": 1,
"aggregate_id": "h_91",
"occurred_at": "2026-09-24T10:00:00Z",
"trace_id": "t_91",
"payload": {
"hold_id": "h_91",
"booking_attempt_id": "ba_2048",
"show_id": "sh_88",
"seat_ids": ["A7", "A8"],
"hold_expires_at": "2026-09-24T10:05:01Z",
"quote_id": "q_310",
"price_version": 7
}
}Optional example fields remain listed in the contract on the left.
Kafka topic + replay policy
A topic isolates a workload, its key controls local ordering, and retention defines how long Kafka can replay it before the raw archive takes over.
A blockbuster launch can create huge search and seat-map traffic. Separate topics stop noisy app events from consuming the same quota, access policy, and recovery window as seat, booking, and payment facts.
Give inventory, payments, catalog, and telemetry independent capacity, access, and failure handling.
Kafka orders only inside one partition, so the key must match the state a consumer rebuilds.
Kafka handles recent recovery; immutable object storage handles older replay and backfills.
SELECTED WORKLOAD
inventory.eventsWHY THIS TOPIC EXISTS
Protect seat-state facts and preserve the order needed to rebuild one show's inventory projection.
BOOKMYSHOW EXAMPLE
For show sh_88, seat A7 must be observed as HELD before SOLD; duplicates are removed by event_id.
PARTITION KEY
show_id
IN KAFKA
7–14 days
AFTER KAFKA
Immutable object archive
FAILURE / DESIGN LIMIT
A hot show can overload one partition, so the waiting room limits admitted writes and partition load is tested.