Section 9: Pulling on Every Thread - Interviewer Deep-Dive Challenges

Executive Summary: With both deep dives done, the interviewer stops asking how the design works and starts asking what breaks it. This section runs eight escalations: the sale-day hot product, the "textbook" Count-Min Sketch, arbitrary windows, real-time ranks, a 20-minute consumer lag, two products both showing #13, a mid-hour recategorization, and per-city lists. Each is laid out as the challenge, what the interviewer is really testing, a model answer built from the numbers ledger, and the senior line to close on. The common lesson: every earlier decision came with a number and a flip trigger, and an escalation checks whether you remember both.

Each question invites you to tear something down; the best answers rarely do. They size the threat, name the decision that covers it, and say where it would flip.

Challenge 1: The Sale-Day Hot Partition

"Sale day. The Nova X5 is 40% of all your events. You keyed by productId, so one partition is on fire. Now what?"

What they're really asking: Do you know a partition's limits, and can you handle skew without breaking the exact merge?

The model answer: Size the claim first. The Nova X5 sells 1M units in 10 minutes: 1,667 events/s, about 333 KB/s on one partition, roughly 11% of the 15,000/s design peak. Even granting 40%:

40% of 15,000 events/s  = 6,000 events/s on one partition
6,000 × 200 B           = 1.2 MB/s
Work per event          = dedup check + buyer-cap check + one map increment

One partition and one Flink subtask handle that easily. Keying by productId only becomes a problem when one product goes well past 50k events/s. Then I'd salt the key and aggregate in two stages:

The salt goes on the Kafka key at the outbox router, for products on a hot list only, so the load spreads across 16 partitions before anything reads it. Stage 1 pre-aggregates per (product, salt, minute); stage 2 is a keyBy on productId. It stays exact because stage 2 sums per-minute aggregates, and addition doesn't care how the work was split. The detail people miss is salting on the buyer hash rather than at random: a buyer's confirmation and cancellation land in the same shard, so the 5-unit cap and the (orderId, lineId, eventType) dedup stay local.

The senior line: "Hot keys are a throughput problem, not a correctness problem. I salt only when the numbers say so, and in a way that keeps the cap and dedup local."

Quick check before moving on: