How would you choose a picking strategy, and what makes a warehouse management system a real-time system?

Travel is the cost you are managing

Before any strategy question, fix the economics. A picker's shift is spent walking, searching, extracting and confirming, and in a conventional pick-face warehouse the walking is the largest of those and the only one software can meaningfully shrink. Extraction time is set by the product and the container, confirmation time by your scan design, but travel is a function of which locations you send someone to and in what order, which is entirely a software decision.

That is why "which picking strategy" is not a preference question. It is a question about your order profile, meaning how many lines an order has, how many units per line, how the demand concentrates across the range, and how the pick face is laid out. Single-line orders in a small range and twenty-line orders across a long range want different answers, and a warehouse that has both usually runs both.

The strategies, and what each one trades

This is a genuinely enumerable list, so it earns bullets:

• Discrete picking. One picker, one order, start to finish. Simplest to reason about, shortest time from release to packed, and the worst travel per line. Right for large orders, low volume, or anything where order integrity matters more than efficiency.
• Batch picking. One picker collects the same item for many orders in one visit, then the batch is sorted downstream. Travel per line collapses when many orders want the same small set of items. The cost moves to the sortation step and to the risk of misallocating units between orders.
• Cluster picking. One trip, several order containers on the trolley, sorted at the point of pick. Keeps orders separate without a downstream sorter, at the cost of a slower, more error-prone confirmation at each stop.
• Zone picking. Each picker owns an area and never leaves it, with orders passing between zones. Travel per picker is minimal and congestion is controlled, but you have introduced a handoff and made the slowest zone the pace of the whole line.
• Wave versus waveless release. Waves group work so that a load can be completed and dispatched together, which is what a cut-off time actually requires. Continuous release keeps labour smooth and reacts to late orders, but makes dispatch completeness something you must track rather than something the wave guarantees.
• Goods-to-person. Automation brings the stock to a fixed station. Travel disappears from the picker's day and reappears as a scheduling problem for the equipment, and your software problem becomes orchestration between the host system and the automation controller.

The answer an interviewer wants is a chain of reasoning ending in a choice, not a taxonomy. Many small orders drawn from a concentrated range points at batch picking with downstream sortation. A wide range with few lines per order and a hard courier cut-off points at cluster picking under wave release. Nobody is impressed by a candidate who recites six strategies and picks none.

Somebody is standing still while your query runs

Here is where the systems question sits. When a picker confirms a pick, the handheld immediately asks for the next task, and until it answers a paid person is looking at a screen. That makes task dispatch an interactive request with a latency budget in the low hundreds of milliseconds, not a planning job. It is the same class of constraint as a checkout page, with the difference that nobody abandons the basket, they just get slower and the shift overruns.

The architectural consequences get missed. The optimisation deciding pick sequence cannot run inside the dispatch call, so it runs ahead and dispatch reads a prepared queue, pushing long work to release time where a wave has seconds to spare. And the task table becomes the hottest thing in the building, with many devices contending, so claiming work is a single conditional write that yields a task or nothing, never a read followed by an update.

The second property that makes it real-time is irreversibility. Once a task is on a device, the picker may already be walking, so the system cannot quietly withdraw it. Cancelling dispatched work is a message to a human, and if the human has already moved the stock, the correct outcome is not a rollback but a putaway task moving it back. Every mutation your planner wants to make has to ask whether the physical action has already started.

Receiving records the first divergence of the day

Receiving is where an advance ship notice describing an inbound load meets the load. Sometimes they agree. Often the quantity is short, an item substituted, a case damaged, or a pallet carries a product not on the notice at all. The receipt is therefore not a confirmation step, it is the first reconciliation of the day, and the discrepancy it records is the input to a supplier claim.

The design decision is whether to receive against the notice or against what is in front of you. Receiving against the notice is faster and propagates the supplier's errors into your stock record, where they surface weeks later as unexplained shortfall. Receiving what you see and reporting the variance is slower at the dock and correct everywhere downstream.

Putaway decides how expensive tomorrow's picking is

Putaway looks like the least interesting step and sets the cost of everything after it. Directed putaway, where the system chooses the location rather than the operator, exists so that fast-moving lines sit close to despatch and near the golden zone, so that units of the same item consolidate rather than fragmenting across the building, and so that a location's capacity and any product restrictions are respected.

That placement decision is a slotting problem that changes as demand changes, which means it decays. A pick face slotted correctly last quarter is slotted wrongly for this quarter's seasonal mix, and the symptom is rising travel per line rather than an error anywhere. Treating slotting as a periodic recomputation rather than a one-off configuration is a mark of someone who has run an operation.

Cycle counting is the correction loop

Stock records drift in a well-run warehouse. Units get damaged, put in the wrong location, picked as the wrong item, returned in unsellable condition or taken. No process prevents this, so the interesting design is detection: counting a subset of locations continuously, weighted so that fast-moving and high-value lines are visited more often than the long tail, with each count producing an adjustment that has a reason code and an audit trail.

The signal to watch is not the count of adjustments but their trend and their concentration. Adjustments clustering in one zone or one operator's work is information about a process fault, and that is what turns counting from a compliance chore into the mechanism that keeps allocation honest. A short at pick time should feed the same loop: it is a free count of that location, and it should trigger an immediate recount rather than only a reallocation.

What weaker answers leave out

The common shape of a weak answer is a good description of pick-path optimisation with no account of what happens when the optimiser is wrong. It will be wrong, because it plans against a stock record and the picker meets the shelf. So the load-bearing part of the design is the short-pick flow: the picker reports what they found, the system reallocates the line to another location or another site if it can, flags the order if it cannot, and adjusts the record so the next picker is not sent on the same errand. A warehouse system is judged on how gracefully it handles the pick that fails, not on the elegance of the route it planned.

Optimise the path if you like, but the system is only credible once a picker reporting an empty shelf produces a reallocation, a stock adjustment and a count task without anyone sending an email.