SYSTEM Cited by 1 source
Walmart inventory-reservations API¶
Walmart's inventory-reservations API is a write-heavy service whose peak-traffic architecture is documented in Walmart Global Tech's 2022 Medium post, surfaced in the High Scalability Dec-2022 roundup.
It's a clean example of stacking three independent scaling patterns on one write-path API.
Three-layer scaling design¶
1. Scatter-gather with sticky session (API gateway → app instance). The API gateway routes each request to a specific app instance based on the DB partition key in the request — so the same partition's requests always land on the same instance. This localizes partition-level state and lets the instance maintain an in-memory view of that partition.
See patterns/sticky-session-scatter-gather.
2. Per-partition actor with mailbox (in-instance concurrency control). Inside the app instance, partition processing is modeled as an actor per partition with a single mailbox. This restricts all processing of a given partition to a single thread — eliminating intra-instance contention for that partition.
Because mailbox messages are queued, the actor can also batch-process multiple same-partition requests in a single DB round-trip. For a write-heavy workload that means fewer writes, better throughput, and lower per-request latency at peak.
See patterns/in-memory-partition-actor.
3. In-memory snapshot-state cache (read-reduction). The actor keeps an in-memory snapshot of the partition's current state, so the dominant read for a write path ("what's the current inventory?") doesn't hit the database. Only the commit hits the DB.
Why the three layers compose¶
Each layer alone would be partial:
- Scatter-gather alone — you'd get partition affinity but per-request contention inside the instance.
- Actor-only — you'd get in-instance isolation but cross- instance writes to the same partition would still collide.
- Snapshot cache alone — you'd reduce reads but not serialize writes.
Stacked, the three layers give:
- No cross-instance contention on a partition (scatter- gather).
- No in-instance contention on a partition (actor+mailbox).
- No redundant reads per write (snapshot cache).
The write path becomes a single thread, on a single instance, batching commits against a single DB partition, with zero reads — the theoretical minimum.
Why it shows up on this wiki¶
Walmart's design is one of the cleanest public descriptions of the partition-affinity-plus-actor-model scaling pattern for write-heavy workloads. The wiki treats the pattern generically in patterns/in-memory-partition-actor — this page is the canonical Walmart-specific instance.