Progress
1 visited · 0 revised
Chapter
9 / 10
On this page
Scale math
Interactive scale calculator
Turn interview assumptions into throughput, storage, and partition math.
Daily events
20.00B
100M x 200
Total daily event volume from the baseline workload.
Raw TB / day
20.0 TB
20.00B x 1 KB
Compressed events only, before replication and lifecycle tiers.
Avg events / sec
231.5K
20.00B / 86,400
Steady-state throughput before prime-time amplification.
Peak events / sec
1.16M
231.5K x 5
Prime-time load that drives queueing and compute decisions.
Peak ingress
1.16 GB/s
1.16M x 1 KB
Network pressure implied by event volume and payload size.
Kafka partitions
151
ceil((1.16M / 10000) x 1.3)
Partition count after safe throughput and headroom.
Bronze hot storage
1.80 PB
20.0 x 90 days
Hot replayable raw history kept immediately accessible.
Silver retention
7.30 PB
(20.0 x 0.5) x 730 days
Trusted cleaned layer kept longer for analytics and correction.
Calculation chain
1. Daily events = active profiles/devices × events per active per day
2. Average events/sec = daily events ÷ 86,400
3. Peak events/sec = average events/sec × peak multiplier
4. Raw TB/day = daily events × average event size
5. Kafka partitions = peak events/sec ÷ safe throughput per partition, then add headroom
Show where cost changes as the platform scales
Retention, partitions, cluster sizing, and serving engine choices all move spend.
Cost framing
Good answers show where Netflix should pay for freshness, where it should pay for replayability, and where it should stop duplicating the same truth across too many systems.
Event backbone
Ingestion backbone
In Netflix context, one blockbuster release can spike playback and QoE traffic at the same time, so the log must survive heavy fan-out without sacrificing replay.
Default position
For a Netflix-style event platform, Kafka is the better default because many downstream consumers need the same durable ordered log for replay, backfill, and independent scaling.
Why this costs real money
This gets expensive when every team wants its own hot replay window and every consumer reads the same playback firehose independently.
When I would change it
Move toward a more managed stream when the team wants lower ops burden and the workload is simpler than a multi-consumer replay-heavy platform.
What actually drives cost here
More partitions raise broker, storage, and rebalance cost during prime-time spikes.
Longer retention helps replay and debugging but directly increases hot storage spend.
Too many tiny topics or consumer groups create platform overhead without adding business value.
What I would actually say
I would keep Kafka as the central cost because it buys us replay, fan-out, and ordered partitions. Then I would control spend with retention discipline, topic hygiene, and sane partition math instead of splitting the backbone too early.
Last reviewed June 2026 · By Prasoon Parashar
Numbers are interview assumptions, not real Netflix internal figures.