Courier Assignment and Bottleneck Detection in Urban Food Delivery
Network analysis and discrete-event simulation of food delivery in Washington, DC.
Summary. With a teammate, I studied food delivery in Washington, DC from two angles: the structure of the road network and the operational decisions a delivery platform makes on top of it. Using the DC OpenStreetMap road network, 2,043 restaurant locations, census tract population, 2024 traffic counts, and a simulated day of 15,188 delivery orders, we identified road bottlenecks, tested road upgrades and closures, compared courier-assignment strategies, and determined a performance-based fleet size. A 500-courier fleet delivered 100% of orders within 45 minutes under both assignment strategies tested; targeted road closures caused about 4.25x more delay than random closures of the same size.
Georgetown University, Network Analysis, Summer 2026. Co-authored with Tianyu Zhao.
The question
Delivery platforms operate on top of two systems that are usually studied separately: the physical road network and the assignment logic that routes couriers through it. We wanted to look at both together. Which roads are actual bottlenecks, not just busy roads? Is there an order volume the network can’t move fast enough to meet? And once you fix the network, which courier-assignment strategy and fleet size actually deliver on time?
Data
We combined open geographic data with simulated delivery demand: the DC road network from OpenStreetMap (via OSMnx), restaurant/fast-food/cafe locations, ACS five-year census tract population, and DDOT’s 2024 Annual Average Daily Traffic counts. The cleaned network keeps the largest strongly connected component: 10,027 intersections, 26,938 directed edges, 1,928 km of streets, with missing speed values imputed from the mean tagged speed for the same road type. Delivery orders are simulated (15,188 orders with lunch and dinner peaks) since public delivery records for DC don’t exist.
Methods
On the network side: travel-time-weighted edge betweenness centrality to rank bottlenecks, compared against observed traffic volume and posted speed; the Clark-Evans ratio to measure restaurant clustering; and targeted-versus-random road upgrade and closure experiments. On the operations side: a discrete-event simulation comparing Nearest Available Courier (NAC) against System-wide Batching (SWB) assignment, run across fleet sizes from 100 to 800 couriers and across lunch/dinner/low-demand periods. We defined the “ideal” fleet as the smallest tested size that delivers at least 99.5% of orders within 45 minutes under both strategies, with diminishing returns (under a minute of further improvement) from the next size up.
Findings
Betweenness centrality found bottlenecks that traffic volume and speed alone missed, only 8% of the top 1% AADT and top 1% betweenness edges overlapped, meaning the busiest-looking roads and the actual structural chokepoints (3rd Street Tunnel, the Southeast Freeway, Florida Avenue) were mostly different roads. A 500-courier fleet could process about 1,461 orders/hour, short of the observed dinner peak of 2,279 orders/hour. Targeted road upgrades improved mean travel time by 0.09%; random upgrades of the same size did almost nothing. Restaurants were strongly clustered (Clark-Evans R = 0.32), and clustered restaurants reached demand about 16% faster than isolated ones. On assignment strategy, SWB was faster with a 200-courier fleet, while NAC edged it out slightly at 500. Targeted road closures caused about 4.25x more delay and 4.5x more route failures than random closures of the same size, affecting both assignment strategies about equally. The 500-courier fleet was the smallest that hit 100% on-time delivery under both strategies.
What I’d do differently
The delivery demand is simulated, which is a real limitation, actual courier GPS traces or platform order logs (even anonymized/aggregated) would let us validate the bottleneck rankings against real congestion rather than modeled travel time. I’d also want to test assignment strategies that use the betweenness rankings directly, routing around known bottlenecks proactively rather than just measuring their effect after the fact.