Multi-Provider Delivery Orchestration

As off-premises dining grew, the company wanted to shift more delivery fulfillment from restaurant employees to third-party delivery providers while continuing to own the guest ordering experience. The technical challenge was not simply integrating a delivery provider. Each provider exposed different APIs, contracts, workflows, coverage, and operating constraints, while Restaurant Operations needed a consistent way to request and manage delivery regardless of which provider ultimately fulfilled the order. The architecture also had to accommodate brand and restaurant-level provider preferences, handle provider unavailability, and return delivery lifecycle changes to the restaurant without coupling the restaurant platform to individual providers.

Last-Mile Delivery was designed as a provider-independent layer between Restaurant Operations and external delivery services. Restaurant systems interacted with a standardized API rather than provider-specific integrations, while the platform selected providers according to restaurant configuration and translated common delivery requests into the APIs, contracts, and multi-step workflows required by each provider. Ordered fallback allowed another eligible provider to be attempted when the preferred provider could not reserve a driver. The architecture also managed the return path as deliveries progressed. Provider webhooks entered through Azure API Management and were processed by Azure Functions, where updates could be validated, normalized, and correlated to the appropriate delivery. The platform then used the existing enterprise event-driven architecture, including Event Grid and Service Bus, to route delivery and driver updates back to the appropriate restaurant without exposing Restaurant Operations to provider-specific lifecycle behavior.

The engineering approach focused on keeping external provider complexity isolated from the rest of the OPD platform. Restaurant Operations understood the delivery capability and its standardized contracts, but not the provider-specific APIs, workflows, or selection logic behind them. Provider-specific implementations, configuration-driven behavior, and controlled integration boundaries allowed delivery providers to vary independently while preserving a consistent operating model for the restaurant.

What began with the integration of a single third-party delivery provider became a reusable delivery capability within the broader OPD platform. Because Restaurant Operations depended on standardized delivery contracts rather than provider-specific implementations, additional providers and changing fulfillment rules could be introduced behind the same operating model without restructuring the restaurant application.

• Expanded beyond the first provider: The initial implementation supported DoorDash Drive, but the architecture was designed for multiple providers from the beginning. Additional providers could be introduced through their own implementations while preserving the standardized interface used by Restaurant Operations.
• Turned provider choice into business policy: Provider availability and preference could be configured by restaurant, allowing the platform to accommodate brand agreements, geographic coverage, and local operating differences without hardcoding those decisions into the restaurant application.
• Added resilience across providers: When the preferred provider was unavailable or unable to reserve a driver, the platform could move through the configured sequence of eligible providers rather than treating the first failed attempt as the end of the fulfillment process.
• Preserved operational flexibility: Restaurant teams retained the ability to request a third-party driver during the eligible order lifecycle, retry after an unsuccessful attempt, or continue with native delivery when appropriate. Automation supported the operation without removing restaurant-level control.
• Extended delivery management beyond reservation: Provider callbacks brought driver and delivery changes back into OPD after the initial reservation. Updates could be correlated to the active delivery and routed to the appropriate restaurant, allowing the fulfillment experience to remain connected as provider-side conditions changed.