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 · Operate the diagram
Assign ownership, protect privacy, reconcile money, and rehearse recovery.
Ownership + contracts
A catalog helps discovery. Owners, tests, and evidence make a BookMyShow dataset dependable.
Responsibility
Own the meaning and completeness of events emitted by one service.
BookMyShow example
The Booking team proves booking_confirmed matches the committed seats, accepted quote, and booking version.
Release evidence
Schema subject, semantic fixtures, release owner, and on-call route.
Quality gates
Select a stage to see the check, failure action, and retained proof.
Gate promise
BookMyShow check
A7 and A8 cannot publish booking_confirmed if either seat failed to become SOLD in the transaction.
When it fails
Reject or roll back, alert the owning service, and publish nothing.
Proof retained
transaction ID + booking version + outbox ID
Finance reconciliation
T+1 closes only when each item is matched or held as an owned exception.
01 / SOURCE
Booking, capture, refund, fee, tax, and movement IDs.
02 / SOURCE
Provider capture, refund, dispute, currency, and settlement reference.
03 / SOURCE
Venue/organiser payable, commission, tax, and payout reference.
T+1 RESULT
Matched OR held exception
amount + age + source IDs + reason + owner
Timing difference
What happened
Gateway settlement arrives after the internal capture.
BookMyShow action
Hold inside the owned window and retry when the statement lands.
Proof to close
Booking, movement, and gateway IDs agree.
Never force-match a daily total. Equal totals can hide one missing capture and one unrelated duplicate refund.
Freshness + health
Select a stage to see what its timestamp means for BookMyShow and what proves it completed.
What this stage means
The server timestamp written when the authoritative booking, seat, payment, or outbox transaction commits. Client-device time is not used for this clock.
BookMyShow example
For booking_confirmed, T0 is the database commit that makes the booking and its seats durable—not when the customer opened checkout.
Evidence retained
commit_at + transaction ID + outbox ID
Measure
p50/p95/p99 age from source commit to the visible version.
Detects
A slow stage despite healthy uptime.
BookMyShow impact
Ops, demand, or settlement silently uses old data.
First response
Find the first timestamp jump, freeze publish, and expose stale age.
Privacy + access
Select a stage to see which BookMyShow data belongs there, why it is needed, and how access is controlled.
Data at this boundary
Direct customer identity, booking contact details, raw device identifiers, and provider-controlled payment references remain inside their owning service boundary.
BookMyShow example
Customer Care may resolve a booking using a phone number, but the shared booking event does not broadcast that phone number.
Protection
Encryption, audited service access, separate credentials, and no shared analytical read.
At source
Name, email, and phone stay in the restricted identity/support boundary.
Distributed form
Pseudonymous customer_sk; no direct email or phone in shared topics.
Who may read
Identity service and approved support; analysts receive the token.
Retention + deletion
Propagate deletion/restriction through raw links, snapshots, features, caches, and exports.
Deletion must finish across the path
What happens
Find the token in eligible raw partitions and apply the approved delete or irreversible anonymization process.
BookMyShow example
A customer deletion request must not leave their searchable identity in archived app events.
Proof of completion
request ID + affected partitions + completion manifest
Failure + recovery
Select an incident to see the affected booking path, safe containment, repair sequence, and proof required before closure.
Selected BookMyShow drill
Affected path
Seat-map read path: Inventory DB → Redis → customer seat map
Customer / operator symptom
Seat maps slow down and cached risk or availability may be stale; holds and sales still belong to the Inventory DB.
Contain safely
Route only admitted reads to the DB, reject excess traffic, and stop treating cached TTL or availability as authority.
BookMyShow repair path
Restore Redis and rebuild current show-seat projections from the Inventory DB; never recreate expired holds from stale cache entries.
Verification before close
Compare AVAILABLE / HELD / SOLD counts for affected shows and prove no expired hold reappeared.
BookMyShow invariant
Redis can accelerate a seat decision but can never create, extend, or confirm seat ownership.
RPO · acceptable loss
Target no loss of an acknowledged committed sale; async cross-region replication alone does not prove zero RPO.
RTO · restore behavior
Measured fence, promote, and booking-resume time; BookMyShow may pause writes to avoid two owners.
BookMyShow proof
Fail over a region, replay idempotent requests, and audit SOLD uniqueness plus outbox continuity.
What BookMyShow rehearses
Prove the old inventory writer is fenced before the new region accepts holds or confirmations.
Evidence required
One active writer, known replication position, zero duplicate SOLD owner for sampled affected seats.
