BookMyShow · Data Engineering · Invariants before tools

Requirements

Pin down seat ownership, workload assumptions, capacity signals, latency, delivery, and money before choosing technology.

Requirement journey

Trace the booking journey before choosing tools

Select one stage to inspect its correctness boundary and recoverable BookMyShow fact.

Discover

Choose another stage above to replace this detail

Search without blocking

Discover

Customers filter by city, date, language, venue, format, and price. Search returns first; impression and click events are sent afterward so telemetry never delays results.

Results

Interaction event

Facts created by Discover

search_submitted · result_impressed · result_clicked · seat_map_opened

Big-data responsibility

Search API → client.events → raw / Silver

Assumptions + capacity lab

Turn BookMyShow behavior into resource signals

One set of controls drives telemetry storage, Kafka retention, hot-sale pressure, and curated capacity without duplicate assumptions.

Illustrative inputs—not BookMyShow actuals. Booking traffic and app interaction events are sized separately; benchmarks validate every throughput constant.

Input assumptions

Daily active users8MSessions / user / day2App events / session40Accepted bookings / day2MHot-sale accepted bookings500KHot-sale duration2hWithin-minute burst10×Hold attempts / booking5App-event burst / second300KCritical events / booking6Kafka retention7 daysCurated compression4:1

Behavior → daily storage

DAU8M→Sessions / day16M→App interaction events640M+Critical domain events12M→Event payload652 GB/day

Hover or focus any block for its formula · 1 KB/event · 6 critical events/booking is an adjustable planning average

Booking demand → inventory pressure

Daily average23.1/svsHot sale mean69.4/s→10× minute burst694/s→5 hold attempts3472/s

Hot sale = 500K accepted bookings / 2h · waiting room limits admitted database work

Daily storage weight

Translate BookMyShow events into bytes

The calculation uses serialized payload size before compression, replication, indexes, metadata, or copies.

App interaction events

Searches, result impressions, clicks, and seat-map opens

640Mevents/day×1 KB

300 MB/s

launch-hour peak throughput

640 GB/day

daily app-event payload

Critical domain events

12 GB/day

2M bookings × 6 events × 1 KB

6 is a planning average, not a fixed protocol.

TOTAL / DAY

652 GB

7-DAY LOGICAL

4.56 TB

7-DAY KAFKA RF3

13.69 TB

ONE YEAR LOGICAL

238.0 TB

CURATED @ 4:1

59.5 TB/year

Capacity formulas

Peak throughputevents/sec × average event size

300K/s × 1 KB = 300 MB/s

Kafka partitionsceil(peak events/sec ÷ (tested events/sec/partition × target use))

ceil(300000 ÷ (5,000 × 0.70)) = 86; test 96

Storage per daydaily events × average event size

640M × 1 KB + 12M × 1 KB = 652 GB/day

Kafka retentionstorage/day × retention days × replication factor

652 GB × 7 days = 4.56 TB; × RF3 = 13.69 TB

Inventory pressure(hot bookings ÷ sale seconds) × minute burst × hold attempts

(500K ÷ (2 × 3,600)) × 10 × 5 = 3472 hold attempts/s

Curated yearly storageone-year logical storage ÷ compression ratio

238.0 TB ÷ 4:1 = 59.5 TB/year

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.

Open design library

Continue learning

NetflixStreaming analytics platform

UberMarketplace data platform

YouTubeVideo analytics platform