Skip to content

Demand Aggregation Window

Demand-batching protocol — instantiates Endpoint Fan-Out Fulfillment

Briefly holds compatible low-density requests until enough accumulate to serve them together as one efficient cluster, instead of dispatching each sparse request on its own.

Low-volume endpoints are expensive precisely because they're sparse — serving each request the moment it arrives means near-empty trips for a single drop. Demand Aggregation Window manufactures the density that isn't naturally there: it holds compatible, non-urgent requests for a bounded time and releases them together once enough have accumulated to form an efficient cluster. Its defining bargain is trading a little latency for a lot of density — a deliberate, capped wait that turns uneconomic one-off drops into a full route. This is a temporal move, distinct from designing fixed territories or re-routing a batch in flight; the window's whole content is a hold-and-release rule keyed to how much demand has built up.

Example

A farm-supply cooperative delivers seed, feed, and parts to farms scattered across a large rural county. Serving each order the day it lands means a truck driving hundreds of miles for a single drop — ruinous per delivery. A Demand Aggregation Window holds non-urgent orders per delivery zone for up to a bounded few days, and releases a batch the moment accumulated orders clear a density threshold: enough weight and enough stops within one corridor to fill a route. A forecast of each zone's typical order pace sizes the window, so orders don't wait longer than the demand rate warrants and the genuinely urgent are carved out to ship immediately. Trucks now run full along dense corridors, cost per drop falls sharply, and the only price is a modest, bounded delay the customer accepted for non-urgent goods.

How it works

The distinguishing logic is hold-until-dense, sized by expected demand:

  • Hold compatible demand. Requests that can share a trip — same corridor, same handling, same window — are pooled rather than dispatched on arrival.
  • Release on a density trigger. The pool ships the instant accumulated volume in a corridor clears the threshold that makes a route efficient — density, not the clock, is the primary release signal.
  • Size the window from a forecast. Expected request pace per zone sets how long the hold can safely run, so sparse zones wait a bit longer and busy ones release fast, without anyone waiting past the demand rate.

Tuning parameters

  • Hold-duration cap — the maximum time a request waits before it ships regardless of density. Longer builds denser clusters but raises latency and risks breaching what recipients tolerate.
  • Density threshold — how full a cluster must be to release. Higher means fuller routes but longer average waits.
  • Compatibility rules — which requests may batch together. Looser rules fill clusters faster but can force awkward mixed routes.
  • Priority carve-outs — which requests skip the window entirely (urgent, SLA-bound). More carve-outs protect service but thin the batchable pool.
  • Window granularity — per-zone versus global holding; finer zones batch more precisely but fragment the pool.

When it helps, and when it misleads

Its strength is that it creates the route density low-volume endpoints lack, converting uneconomic one-off drops into efficient clusters for the price of a small, bounded, agreed delay. Its failure mode is intrinsic: it trades latency for efficiency, so it is poison for time-critical endpoints — and if the window is set by cost alone, the delay silently lands on recipients who never consented to it. The classic misuse is stretching the hold to flatter utilization figures ("look how full our trucks run") while service quietly degrades — optimizing the vehicle rather than the recipient. The discipline is to cap the hold with an inviolable latency ceiling, carve out the genuinely urgent, and track recipient wait time, not just load factor.[1]

How it implements the components

Demand Aggregation Window realizes the batch-forming side of the archetype — the components a temporal-pooling protocol fills, not the routing, territory, or completion machinery:

  • demand_forecast — the window is sized from a forecast of each zone's request pace, so the hold is long enough to accumulate a cluster but no longer than demand warrants.
  • route_density_and_cluster_rule — the release rule is a density threshold: requests are held until accumulated volume in a corridor clears the bar that makes a route efficient, then dispatched together.

It does not re-route an already-formed batch in flight (fan_out_geometry_model) — that is Dynamic Route Optimization; nor does it design the fixed spatial territories the clusters run within, which is Route Clustering and Territory Design.

References

[1] Nagle's algorithm in TCP networking holds small outgoing packets briefly so they can be combined into fuller segments, trading a little latency for much better efficiency — the same bargain a Demand Aggregation Window strikes. Its well-known downside, degraded responsiveness for latency-sensitive traffic, is exactly why urgent endpoints need a carve-out from the hold. ↩