How many DC-to-DS replenishment cycles per day are optimal?

Typically 2-4 per day for mid-density networks, up to 6 per day for hyperdense metros with top-SKU velocities above 300 units per day per store. The optimal cadence balances truck utilization against stock-out risk.

Can replenishment support multi-merchant marketplace models?

Yes. In marketplace quick commerce (multiple merchants sharing dark store space), replenishment is orchestrated per-merchant with segregated inventory tracking but shared truck capacity for cost efficiency.

How does the system handle temperature-sensitive SKUs?

Multi-temp truck design plus temperature-excursion monitoring during transit. SKUs are segregated by temperature zone at the DC and on the truck, with excursion alerts via Atlas that can trigger re-dispatch from a closer store if needed.

What happens when a DC runs out of an SKU?

Astra routes the replenishment from an alternate DC or a sister store with excess inventory. Network-level inventory repositioning is a core feature, not an exception handler.

How long does dark-store replenishment take to implement on an existing network?

Typical deployments are 3-6 months for network of 50-200 stores, including forecasting model tuning, route optimization setup, and integration with existing WMS and POS systems. Networks above 500 stores phase over 6-9 months.

DC-to-dark-store replenishment: the upstream logistics that make 10-minute delivery possible

A dark store is only as good as the replenishment truck that fills it. Run out of the top-50 SKUs and the 10-minute promise is a broken promise, regardless of how elegant the pick and dispatch mechanics are. The operators running sub-15-minute quick commerce at scale have built a replenishment layer that moves goods from distribution centers to dark stores multiple times per day — a middle-mile operation very different from weekly grocery store replenishment.

One of India’s largest quick-commerce players with ~1M orders/day and 1,000+ dark stores runs this replenishment layer on Shipsy — see a detailed case study. The same mechanism underpins LATAM, SEA, and MENA quick-commerce deployments at smaller scale.

Why weekly-grocery replenishment breaks in quick commerce

A traditional grocery store receives replenishment 2-4 times per week, with pallet-level shipments and 24-48 hour order-to-shelf cycles. The model is designed around a store that carries 20,000+ SKUs on shelves and can tolerate multi-day stockouts on long-tail items.

Quick-commerce dark stores carry 2,000-8,000 SKUs in a compressed footprint, turn the top-100 SKUs 5-15 times per day, and lose revenue on every SKU that goes out of stock for more than 30 minutes during peak hours. The replenishment model has to be completely different.

The three structural differences that break the weekly model:

High velocity top-SKUs need multi-daily replenishment. A top-SKU selling 200 units per day in a dark store cannot wait for the next day’s truck if its buffer is exhausted by 14:00. It needs a refill by 15:00.

Long-tail SKUs need precision, not volume. A dark store carrying a promotional SKU for a short window cannot over-stock — shelf space is too constrained. Replenishment has to match forecast demand within narrow bounds.

Multi-temperature zones in a single dark store. Quick-commerce baskets mix ambient (staples), chilled (dairy), frozen (ice cream), and sometimes hot-ready. The replenishment truck often has to support all four temperature zones from a single DC.

What AI-native DC-to-DS replenishment looks like

Dimension	Weekly grocery model	Quick-commerce model
Replenishment frequency	2-4 per week	2-6 per day
Order cycle time	24-48 hours	2-6 hours
Store capacity forecast	Shelf-inventory targets	Real-time stock-on-hand + demand forecast
Truck design	Pallet, single-temp	Multi-temp, roll-cage or tote
Route planning	Fixed weekly routes	Dynamic per-replenishment-cycle routes
Load planning	Pallet-level	SKU-level with buffer logic

Shipsy’s middle-mile layer orchestrates this. The planning horizon is the next 2-6 hour window, the forecasting layer consumes real-time POS and stock-on-hand signals, and the routing layer builds per-replenishment-cycle routes rather than fixed weekly ones.

How the mechanism works through a day

05:00 — Morning replenishment plan. Astra runs the day’s first replenishment plan based on overnight sales, current stock-on-hand per store per SKU, and demand forecast for the morning peak (07:00-10:00). The plan specifies SKU-level quantities per store, assigns them to multi-temp trucks departing the DC, and sequences the stops.

07:30 — Morning wave departs DC. Trucks leave with cross-docked loads. The first stores receive delivery by 08:00, in time for morning peak demand.

11:00 — Mid-day forecast refresh. Astra refreshes the forecast for afternoon peak based on actual morning sales. Stores running ahead of forecast for specific SKUs get top-up shipments added to the mid-day wave.

13:00 — Mid-day wave departs DC. Top-up shipments go out, sized per store per SKU based on the refreshed forecast.

17:00 — Evening wave. A third wave supports evening peak (18:00-22:00), sized against the refreshed forecast.

Overnight — Inventory repositioning. Atlas runs inventory repositioning across the network — SKUs overstocked in one store get redirected to stores running low, minimizing network-level out-of-stocks.

This multi-wave cadence is what protects the 10-minute downstream promise. A store is never more than 4-6 hours from its next replenishment, and the replenishment is sized against actual demand, not a static weekly plan.

The role of the forecasting layer

Replenishment precision is almost entirely a forecasting problem. A forecast that is wrong by 10% on a high-velocity SKU either creates waste (overshoot) or stockouts (undershoot). The tolerable error band is narrow.

Shipsy’s forecasting layer combines four signal streams.

Stream one — store-level historical sales. SKU-level hourly sales over the past 90-180 days, seasonalized, weekdayed, and promo-flagged.

Stream two — real-time POS. Current-day sales through the forecast horizon, allowing mid-day forecast correction.

Stream three — external demand drivers. Weather, local events, competitor promotions, macro holidays. These drive systematic deviations from historical patterns.

Stream four — network-level substitution. When store A is out of SKU X, demand shifts to SKU Y or to store B. The forecasting layer models this cross-substitution explicitly.

The resulting forecasts support replenishment decisions within tight error bands — typically 5-8% mean absolute error on top-100 SKUs, which is the precision needed for 4-6 hour replenishment cycles.

What this means for quick-commerce operators scaling the network

Three structural shifts separate operators running profitable dark stores from those burning cash on overstocked shelves.

First, move to multi-daily replenishment as a design principle. Weekly or even daily replenishment is incompatible with sub-15-minute SLA at high SKU velocities.

Second, invest in SKU-level forecasting, not store-level. Store-level forecasts are too coarse. The forecast that matters is “how much SKU-123 will store-45 sell between 14:00 and 18:00 tomorrow.”

Third, integrate downstream and upstream in one decisioning layer. Replenishment, pick, dispatch, and delivery are one system. Separate systems with batch integrations lose the precision needed to hit 10-minute SLAs at high scale.

For context on the downstream dispatch mechanics, see the dark-store dispatch operations playbook. For vertical context, visit the quick-commerce industry page or explore Shipsy’s middle-mile product.