Section 8: One Event, Twelve Thousand Flips - Deep Dive: Sharded Evaluation

Executive Summary: A verified price change has to become the exact set of watches it fires: none missed, none fired twice. We align price-changes partitions with database shards, wrap Section 5's crossing band in a paged conditional UPDATE that writes outbox rows in the same transaction, and show why a mid-band crash is harmless. Then come re-arming, the 500K-watcher hot product, the race with an edit, and two pushbacks.

Alignment: Partition N Owns Shard N

Interviewer: "The change detector just emitted B0EXAMPLE4: 39999 → 27800, priceVersion 812. Who handles it?"

You: "Exactly one evaluator, and it never leaves one shard."

Watches, products and the price-changes topic all use the same key, hash(asin) into 64 logical shards (D5). Kafka partition N carries the events for DB shard N's ASINs and has a single consumer in the evaluator group. That buys per-ASIN ordering (one partition is one log), local transactions on one Postgres shard, and small load: Prime Day's 500 change events/s ÷ 64 ≈ 8/s per shard.

The 64 logical shards sit on 8 physical nodes, 8 each. Rebalancing moves a whole logical shard; the hash never changes, so evaluator 37 simply reconnects to wherever shard 37 now lives. Going past 64 is a planned split of partitions and shards together, never a rehash under load.