Design Warehouse Management

Problem Statement & Warehouse Context

A warehouse management system (WMS) is the operational brain inside a fulfillment center: it turns abstract order lines from an OMS into concrete physical work. It receives pallets, slots cartons into bins, releases pick waves, guides associates and robots along travel paths, verifies weights, prints carrier labels, and emits the ship-confirm events that decrement corporate inventory. Where most systems measure correctness in HTTP status codes, a WMS is measured in physical units — a silent double-pick costs real money, and a missed ship-confirm breaks a customer promise. Interviewers at Amazon, Walmart, and Target probe exactly this: do you understand that the ledger inside the building is law, and that the system's job is to keep bits and atoms in agreement?

Naming the actors early frames the failure modes, because each actor's mistake has a distinct, expensive consequence.

The scale is large but the difficulty is not raw QPS — it is correctness under contention across many physically independent buildings. Assume 120 active fulfillment centers, 18 million sellable SKUs (not all stocked in every building), and 2.4 million outbound order lines a day globally, with a 3x peak on Prime-like events and roughly 14 picks per order on average. A mega-site runs thousands of associates and hundreds of concurrent handheld sessions at peak shift.

The defining architectural fact follows from that physical independence: the unit of strong consistency is the facility, not the enterprise. Each building's inventory ledger is strongly consistent within itself — a bin's quantity has a single authoritative writer — while the corporate cross-channel inventory view is eventually consistent, fed by events. Stating that split (facility-strong, corporate-eventual) up front is what makes every later decision about sharding, consistency, and events coherent.