Inventory Management System Design: From SKU to Shipment

Every e-commerce platform, retail chain, and marketplace eventually faces the same challenge: tracking what you have, where you have it, and ensuring you never sell more than you own. Inventory management system design sits at the intersection of consistency, performance, and real-time accuracy.

SKU Management#

A SKU (Stock Keeping Unit) is the atomic unit of inventory. Each unique product variant — size, color, configuration — gets its own SKU.

A well-designed SKU schema includes:

• SKU code — A human-readable, hierarchical identifier (e.g., SHIRT-BLU-M-001).
• Product reference — Links the SKU to its parent product for catalog display.
• Attributes — Key-value pairs describing the variant (color: blue, size: M).
• Unit of measure — Each, case, pallet, kilogram.
• Barcode/UPC — For warehouse scanning and POS integration.
• Weight and dimensions — Required for shipping cost calculation and warehouse slotting.

Avoid embedding business logic in SKU codes. Use them as identifiers and store attributes separately for flexible querying.

Stock Tracking#

At its core, inventory is a ledger. Every stock movement creates a journal entry:

The current stock level is the sum of all journal entries. Maintaining both a running balance (for fast reads) and the full ledger (for auditability) is the standard approach.

Available stock is not just what is physically on the shelf:

Available = On Hand - Reserved - Allocated - Damaged + In Transit (if you sell ahead)

This formula drives every "Add to Cart" and "Buy Now" decision.

The Reservation Pattern#

The reservation pattern prevents overselling during the gap between "customer clicked buy" and "warehouse confirmed shipment":

1. Reserve — When a customer adds to cart or initiates checkout, decrement available stock by placing a soft reservation with a TTL (e.g., 15 minutes).
2. Confirm — On successful payment, convert the reservation to a hard allocation.
3. Release — If the TTL expires or payment fails, release the reservation back to available stock.
4. Fulfill — When the item ships, convert the allocation to a confirmed deduction.

Implement reservations with atomic operations. In PostgreSQL:

UPDATE inventory
SET reserved = reserved + 1
WHERE sku_id = $1
  AND (on_hand - reserved - allocated) >= 1
RETURNING *;

The WHERE clause ensures you never reserve more than what is available. If the update affects zero rows, the item is out of stock.

Overselling Prevention#

Overselling — selling inventory you do not have — is the cardinal sin of inventory management. Defense in depth:

Database-level constraints — Use CHECK constraints to enforce on_hand >= reserved + allocated. This is your last line of defense.

Atomic compare-and-set — Never read stock, compute availability in application code, then write. Use a single atomic UPDATE with a conditional WHERE clause.

Pessimistic locking — For high-contention SKUs (flash sales), use SELECT FOR UPDATE to serialize access. Adds latency but guarantees correctness.

Optimistic concurrency — Add a version column. Read the version, compute the update, and write only if the version has not changed. Retry on conflict.

Queue serialization — For extreme contention, funnel all stock operations for a SKU through a single-threaded consumer (e.g., a Kafka partition keyed by SKU).

Warehouse Management#

A warehouse is not a single bin — it is a hierarchy:

Warehouse
  └── Zone (Receiving, Storage, Packing, Shipping)
       └── Aisle
            └── Rack
                 └── Shelf
                      └── Bin (location)

Each bin holds one or more SKUs with a quantity. The bin-level inventory model enables:

• Directed putaway — Route inbound stock to optimal bins based on velocity, size, and zone rules.
• Pick path optimization — Sequence pick lists to minimize travel distance through the warehouse.
• Cycle counting — Count a subset of bins daily rather than shutting down for a full physical inventory.
• FIFO/FEFO enforcement — Pick from the oldest batch (First In, First Out) or earliest expiry (First Expiry, First Out).

Multi-Warehouse Routing#

When inventory spans multiple warehouses, the system must decide where to fulfill each order:

Proximity routing — Ship from the warehouse closest to the customer to minimize transit time and cost.

Inventory balancing — Prefer warehouses with excess stock to prevent regional stockouts.

Split-shipment avoidance — Try to fulfill the entire order from a single warehouse, even if it is not the closest, to reduce shipping costs.

Cost optimization — Factor in warehouse-specific labor costs, carrier rates, and zone-based shipping prices.

A routing engine evaluates these factors with a weighted scoring model:

Score = w1 * proximity + w2 * stock_level + w3 * split_penalty + w4 * shipping_cost

The warehouse with the highest score wins the fulfillment assignment.

Demand Forecasting#

Accurate forecasts drive purchasing, staffing, and warehouse capacity planning:

Time-series models — ARIMA, Prophet, or exponential smoothing on historical sales data. Capture seasonality, trends, and cyclical patterns.

Machine learning — Gradient-boosted trees (XGBoost, LightGBM) trained on features like promotions, holidays, weather, and competitor pricing.

Safety stock calculation — Buffer stock to absorb demand variability:

Safety Stock = Z * sigma_demand * sqrt(lead_time)

Where Z is the service level z-score (1.65 for 95%) and sigma_demand is the standard deviation of daily demand.

Reorder points — Trigger a purchase order when stock drops below:

Reorder Point = (Average Daily Demand * Lead Time) + Safety Stock

Automate reorder point calculations and surface them in dashboards for procurement teams.

Real-Time Inventory Sync#

Inventory must be consistent across all sales channels (website, mobile app, marketplace, POS):

Event-driven updates — Every stock movement publishes an event to a message bus (Kafka, SNS). Channel adapters consume events and update their local views.

Inventory cache — A Redis-backed available-stock cache serves high-frequency read queries (product pages, search results). Cache TTL under 5 seconds balances freshness with throughput.

Webhook notifications — Push stock level changes to third-party marketplaces (Amazon, Shopify) to prevent overselling on external channels.

Conflict resolution — When two channels sell the last unit simultaneously, the reservation pattern (atomic decrement) ensures only one succeeds. The other receives an out-of-stock response.

E-Commerce Integration#

Inventory connects to nearly every part of an e-commerce platform:

• Product catalog — Display "In Stock," "Low Stock," or "Out of Stock" badges.
• Cart and checkout — Validate availability at add-to-cart, at checkout start, and at payment confirmation.
• Order management — Allocate inventory on order creation, deallocate on cancellation.
• Returns and exchanges — Restock returned items after quality inspection.
• Promotions — Reserve inventory for flash sales or bundle deals before the event starts.
• Analytics — Track sell-through rates, days of supply, and inventory turnover ratios.

Architecture Overview#

Sales Channels (Web, Mobile, POS, Marketplace)
    |
    v
API Gateway / BFF
    |
    v
Inventory Service
    |--- Stock Ledger (PostgreSQL)
    |--- Availability Cache (Redis)
    |--- Event Publisher (Kafka)
    |
    v
Warehouse Management System
    |--- Bin-level tracking
    |--- Pick/Pack/Ship workflows
    |
    v
Fulfillment Routing Engine
    |--- Multi-warehouse scoring
    |--- Carrier selection

Key Takeaways#

1. Model inventory as a ledger with journal entries for full auditability and accurate running balances.
2. Use atomic database operations and the reservation pattern to prevent overselling under concurrency.
3. Track inventory at the bin level within warehouses for efficient putaway, picking, and cycle counting.
4. Implement multi-warehouse routing with weighted scoring across proximity, stock levels, and cost.
5. Automate reorder points and safety stock calculations using demand forecasting models.
6. Sync inventory across all channels in real time using event-driven architecture and a fast cache layer.

---

If you found this guide useful, explore more system design deep dives at codelit.io.

This is article #215 in the Codelit engineering blog series.