Warehouse and Inventory Management System

Stock accuracy and fulfillment

Design a warehouse management system that tracks every unit from receiving to shipping, reserves stock so no order is promised units that are not there, picks efficiently and chooses which warehouse ships each order.

Overview

A warehouse management system (WMS) is the software that runs a fulfillment center. It knows which bin holds which product, tells workers where to put incoming stock and what to pick next, and records every movement. An order management layer above it decides which warehouse ships each order.

The problem is hard for two reasons. First, the database must match the shelves. Stock changes only when a person or machine scans it, scans arrive late or twice, and a count can show that a bin holds fewer units than the system thinks. Second, stock is shared: many orders compete for the same units, and checkout must never promise a unit that is already promised to someone else.

The rest (slotting, pick paths, waves) is about labor: pickers spend much of their shift walking, and the software decides how far.

Questions to ask first

One warehouse or a network? — A network of 50 warehouses, one database cluster per region
How many orders? — About 1 million a day, 3 lines each, peak hour at 3 times the average
Is stock tracked by bin or only by warehouse? — By bin; lots and expiry dates where the product needs them
Can checkout oversell and fix it later? — No: a reservation is a promise, and it must be exact
Does the warehouse keep working if the link to the cloud drops? — Yes: scanning and picking must not stop
Robots and conveyors? — Out of scope; the WMS sends them tasks through an adapter

What you will be able to do

Keep on hand, reserved and available stock correct with a ledger, and explain why counts are never simply overwritten.
Reserve several lines of an order all or nothing, in SQL that is safe under concurrency and cannot deadlock.
Route an order to a warehouse by cost, and say when to split it.
Explain slotting, waves and pick paths, and why a heuristic is enough for pick routes.
Keep scanning when the network drops, without counting any scan twice.

Key concepts

On hand, reserved, available
Append-only stock ledger
All-or-nothing reservation
Idempotent scans
Order routing and split shipments
Velocity slotting (ABC)
Pick path heuristics (2-opt)
Waves and batch picking
Cycle counting

Functional requirements

Receive inbound shipments against an advance ship notice and put units away into bins
Track stock per warehouse, bin, SKU and lot: on hand, reserved and available
Reserve stock for an order all or nothing, and release it on cancel
Choose the warehouse (or two) that ships each order
Create pick tasks grouped into waves or batches, with a walking route
Record pack and ship scans; shipped units leave the stock
Schedule cycle counts and record differences as adjustments

Non-functional requirements

Never reserve more units than are on hand (strict correctness)
Each scan changes stock exactly once, even when a handheld retries
Routing plus reservation answers checkout in under 200 ms at p99 (a target we chose)
Availability shown on the storefront may lag by a few seconds; the reservation may not
Each warehouse keeps receiving, picking and shipping through a network outage
Every stock change is explainable from the ledger for audits

Interview questions

How do you make sure two orders never get the same last unit?
Why keep a ledger when you already have balances?
How do you choose which warehouse ships an order?
How do you compute the pick route, and why not the optimal one?
A handheld loses its connection mid-scan. What happens?
What is slotting and how do you decide when to re-slot?
How does a cycle count fix a wrong balance?
How do you shard, and what about a flash sale on one SKU?