How I Rebuilt WMS Picking Algorithms: Supply Chain Best Practices from an Engineer

Last Singles Day at 10 PM, I was squatting in the warehouse server room, staring at the monitoring screen as CPU usage spiked. The WMS picking queue had over 3,000 backlogged requests, pickers were running around with PDAs, and the system kept issuing new waves. That's when I realized our "smart" WMS was just a robot that issued tasks—it didn't understand the rhythm of supply chain at all.

TL;DR: I spent three months rebuilding the picking engine of Flash Warehouse WMS, from wave strategy to path optimization to load balancing, stepping on every pitfall along the way. Today, I'll share from an engineering perspective that the best practices in WMS are not about piling on features, but about teaching the system to "breathe."

闪仓 WMS · 示意图

内容概览

Wave Strategy: Don't Make Pickers Run Marathons

That night, I opened the WMS wave configuration and found the system was generating waves every hour on a first-come-first-served basis. Result: morning had few orders, small waves, pickers idle; afternoon orders exploded, waves flooded in, pickers exhausted. I realized it wasn't an algorithm problem—it was a strategy problem.

The real wave strategy should be like traffic lights, dynamically adjusting to traffic flow

I rebuilt the wave engine with three core parameters: cutoff time, order similarity, and device load.

Dynamic Cutoff Time

Previously fixed hourly generation; now the system dynamically calculates based on order arrival rate. If orders exceed a threshold in an hour, wave intervals shorten to 20 minutes; during quiet times, they stretch to 2 hours.

Order Similarity Clustering

I wrote a clustering algorithm to group orders with similar picking paths. For example, orders all from "Zone A, Shelf 3" can be picked together, reducing walking distance by 60%.

闪仓 WMS · 示意图

Order Similarity Clustering

Device Load Balancing

Comparison: Static vs Dynamic Waves

Source: Flash Warehouse internal test environment, July 2026

Path Optimization: From Maze to Shortcut

Previously, picking paths were straight-line planning—system told pickers "go to A1, A2, B3" without considering aisle congestion. Two pickers would meet in narrow aisles, one pushing a cart, the other carrying goods, wasting time yielding.

I borrowed Google Maps' real-time traffic idea and implemented dynamic path planning in the warehouse

Real-Time Congestion-Based Rerouting

Each picker's PDA reports location every 5 seconds; the system dynamically adjusts paths based on real-time distribution of all pickers. If an aisle is occupied, the system automatically reroutes.

Shelf Heatmap

I analyzed picking frequency for each shelf position and generated a heatmap. High-frequency items were moved to "golden positions" near the shipping area; low-frequency items were relocated to corners. After adjustment, average picking time decreased by 22%.

闪仓 WMS · 示意图

Shelf Heatmap

Comparison: Static vs Dynamic Paths

Inventory Allocation: Don't Put All Eggs in One Basket

Once, a best-selling SKU was stored in a single location, which got blocked by a large pallet. A picker spent 20 minutes moving it. I realized inventory allocation strategy directly impacts picking efficiency.

Good inventory allocation should be like an investment portfolio, balancing efficiency and risk

Multi-Location Decentralization

I spread each SKU across at least 3 different zones. The system recommends the optimal location based on picking tasks; if one location is congested, it switches to a backup.

ABC Classification and Slotting

SKUs are classified by sales volume: A (high frequency), B (medium), C (low). A-items are placed on shelves nearest to the shipping area; C-items farthest. After adjustment, picking time for A-items dropped by 40%.

闪仓 WMS · 示意图

ABC Classification and Slotting

Load Balancing: Don't Let the Server Crash on Singles Day

Back to the opening scene—on Singles Day night, CPU hit 95%, database connection pool exhausted. I wrote rate-limiting and degradation code overnight to barely survive. Post-mortem, I realized the system lacked elastic scalability.

WMS architecture must stretch like a rubber band, not be rigid like steel

Database Read-Write Separation

Order queries and inventory updates were split into different database instances. Read layer uses Redis cache; write layer uses sharded clusters, distributing write pressure across 4 nodes.

Async Task Queue

Picking task generation changed from synchronous to asynchronous: orders enter a queue first, worker threads consume gradually. If queue length exceeds a threshold, compute nodes auto-scale.

闪仓 WMS · 示意图

Async Task Queue

Comparison: Sync vs Async Architecture

Summary

Those three months of rebuilding the picking engine meant coding until dawn every day. But seeing the system rock-solid during Double 12, pickers no longer running marathons, customers not complaining about shipping delays—it was all worth it. The best practices of supply chain management in WMS are not about how fancy the tech is, but about making the system understand the warehouse's real rhythm: speed up when needed, slow down when needed, detour when needed.

Key Takeaways:

• Wave strategy should be dynamic, not one-size-fits-all
• Path optimization must avoid real-time congestion, not be a maze
• Inventory allocation should decentralize, not bet on one location
• System architecture must scale elastically, not harden against traffic
• All optimizations need data validation, not gut feelings

---

References

1. Fortune Business Insights WMS Market Report — Referenced for WMS market growth data
2. Gartner Supply Chain Research — Referenced for supply chain best practices
3. McKinsey Operations Insights — Referenced for warehouse efficiency optimization