marketplace_mixed_workload vulnerable to hot

marketplace mixed workloadVulnerable Tohot partition

Source: Workload·Target: Failure Mode

Summary

Marketplace workloads are highly susceptible to hot partitions: viral listings, celebrity sellers, and flash sales concentrate enormous traffic on a small number of items or sellers, overwhelming the shards or database rows that store their data.

Evidence

·eBay engineering documented hot partition issues on high-demand auction items during closing bidding windows
·Amazon's Cyber Monday flash deals create 100-1000x normal load on specific item partitions
·DynamoDB hot partition adaptive capacity was specifically designed for marketplace-style skewed access
·Inventory reservation on a single hot item creates severe row lock contention in relational systems
·Etsy's flash sale architecture uses write sharding and Redis-backed counters to handle viral listing traffic

Operational Context

·Identify partition key candidates with high-traffic variance: seller_id and listing_id are common hot key candidates
·For inventory reservation, use Redis atomic DECR with a Lua script rather than relational row locks
·Write sharding (randomized key suffix) distributes writes across multiple shards at the cost of scatter-gather reads

Tradeoffs

·Write sharding for viral items requires a read aggregation step: adds latency for total inventory reads
·Pre-sharding hot keys requires identifying them before the spike: reactive resharding is too slow
·Redis-based inventory counters sacrifice ACID guarantees: requires reconciliation with the relational database

Evidence grounding

Grounded, 5 supporting items

Hot partition from marketplace demand concentration is extensively documented in eBay, Amazon, and Etsy engineering posts. Flash sale and viral product scenarios are the canonical examples.