How to Build Template 10: Food Delivery Platform

How to Build Template 10: Food Delivery Platform

This template shows how to model a food delivery platform at the System Context level. It is the clearest example of a three-sided marketplace in software architecture — a system that must simultaneously serve consumers who want food, restaurants that cook it, and couriers who deliver it. Adding a third actor to the classic two-sided marketplace is not just an incremental change. It is a structural shift that multiplies the coordination complexity, the number of real-time actors, and the surface area of external integrations.

Most food delivery post-mortems and scaling war stories trace back to this triadic coordination problem: a consumer places an order, a restaurant must prepare it in a narrow window, and a courier must arrive at exactly the right moment — not too early (wasting courier time and cost), not too late (letting food go cold). Getting this three-way timing constraint visible in the very first architecture diagram is the fastest way to align engineers, product managers, and operations teams on what the platform actually is.

What This Template Shows

• Three distinct user populations — consumers, restaurant managers, and couriers — each with their own dedicated application and workflow
• Internal operations and support roles that keep the marketplace healthy at scale
• The platform as the real-time orchestrator of a time-sensitive, location-dependent transaction
• External systems for marketplace payment splits, maps and ETA, real-time state synchronization, anonymized communications, restaurant POS integration, and analytics
• The merchant onboarding and catalog management surface as a distinct and ongoing integration concern

This is the right level when you need to explain the full actor and system landscape before zooming into dispatch services, order orchestration pipelines, or fulfillment workflows.

Embedded Diagram

Why This Context Diagram Works

The most important signal the diagram conveys immediately is the three-sided nature of the marketplace. Most people who have not built a food delivery platform mentally model it as two-sided: customers on one side, delivery drivers on the other. The restaurant is invisible in that model — just a source of food. The diagram corrects that assumption before any design conversation begins.

The restaurant is not a passive participant waiting to be picked up from. It must:

• receive the incoming order in real time and signal acceptance within a strict timeout
• confirm menu item availability and flag substitutions
• prepare the food within a predicted time window that the platform communicated to the courier dispatch system
• signal order readiness precisely so the courier arrives within minutes, not much earlier or later
• manage its own menu catalog, item availability, opening hours, and holiday schedules through the merchant portal

That means the Restaurant App is a first-class product with its own hardware (a tablet), its own technical reliability requirements (restaurants cannot afford the tablet going offline during dinner rush), its own onboarding flow, and its own support tier. Architecturally, the restaurant must be designed for as carefully as the consumer app — perhaps more carefully, because a degraded restaurant experience creates cascading failures for consumers and couriers simultaneously.

The second key signal is three-stage time coupling. Ride-sharing has one hard real-time constraint: match rider to driver. Food delivery has three sequential constraints that must all be met within a narrow total window: order placed to restaurant acknowledgment, restaurant preparation time to courier readiness, courier pickup to consumer delivery. If restaurant prep takes longer than estimated, the courier arrives and waits — reducing courier utilization and increasing idle cost. If the platform dispatches the courier too early, the same problem occurs. If it dispatches too late, food sits and cools. The dispatch timing algorithm is one of the most technically demanding components of the entire platform, and its existence is motivated entirely by this three-party coordination structure.

Core Elements To Include

People

Consumer The demand side of the marketplace. Consumers browse the restaurant catalog (filtered by cuisine type, dietary requirements, distance, rating, and delivery time estimate), customize their order at item level, checkout, and then track their order through two distinct phases: restaurant preparation and courier delivery. Consumer experience is driven by three variables: accuracy of the ETA shown at checkout, real-time transparency during the wait, and reliability of the order when it arrives. All three have direct architectural implications — ETA accuracy requires integrating preparation time estimation with live traffic-aware routing; real-time transparency requires a live tracking feed; order accuracy requires a reliable channel from the consumer's cart through the restaurant's kitchen display system.

Restaurant Manager The supply side for food. Restaurant managers interact with a dedicated tablet application that receives incoming orders in real time, shows order details formatted for kitchen reading (item names, modifiers, quantities, special instructions), provides a timer showing how long the courier has been waiting, and allows marking the order as ready for pickup. Behind the tablet app is a merchant portal for managing the restaurant's menu — adding items, updating prices, toggling item availability when ingredients run out, uploading photos, setting opening hours, and running promotional discounts. Onboarding a new restaurant involves menu digitization (often requiring a human operator to photograph, transcribe, and categorize the menu), payment account setup for receiving proceeds, and hardware provisioning and support for the tablet.

Courier / Delivery Partner The logistics side. Couriers toggle themselves available, receive delivery assignment notifications with pickup restaurant and drop-off address, navigate to the restaurant for pickup, confirm pickup on the app, navigate to the delivery address, and confirm delivery with a photo or signature. Courier experience design is heavily governed by earnings optimization — couriers want to minimize idle time and maximize deliveries per shift. The platform's dispatch algorithm must simultaneously optimize for consumer delivery speed, restaurant wait time, and courier route efficiency, which creates inherent tension. Like ride-share drivers, couriers require identity verification and, in markets where they operate motor vehicles, background screening and driving record checks.

Operations Manager Internal staff responsible for marketplace health. Operations managers monitor order volume versus courier supply by geographic zone and time of day. When supply is low in a zone, they activate courier incentive bonuses. When a restaurant's prep times are spiking, they investigate and potentially deboost the restaurant in rankings to manage consumer expectations. They manage city-level launch operations, restaurant partner relationships at scale, and major event demand planning (sporting events, holidays, severe weather). Their primary tooling is the internal operations dashboard backed by real-time analytics — not the consumer or restaurant app.

Support Agent Handles consumer complaints (wrong items, missing items, damaged food, late delivery, billing disputes), courier complaints (restaurant not ready, delivery address not accessible, consumer not reachable), and restaurant complaints (tablet not receiving orders, payment discrepancies). Support agents need access to the full order audit trail: every state change with timestamps, the courier's GPS path, the restaurant's prep time log, all in-app communications between parties, and the payment transaction. They must be able to issue refunds to consumers, compensate couriers for courier-fault issues being incorrectly attributed, and escalate restaurant performance concerns.

Main System

Food Delivery Platform The central real-time orchestrator. It receives orders from consumers, routes them to restaurants within seconds, estimates preparation time and dispatches couriers at the mathematically optimal moment, tracks the full order state from placement through delivery, processes a three-way payment split, and maintains separate reputation systems for both restaurants and couriers. The platform also owns the restaurant catalog as a data asset — menus, photos, ratings, opening hours across thousands of restaurant partners — which is itself an ongoing data operations challenge because menus change constantly and must be kept accurate or consumer trust erodes.

External Systems

Marketplace Payments Platform (Stripe Connect / Braintree Marketplace) A standard consumer payment is a two-party transaction: consumer pays, merchant receives. A food delivery payment is a three-party transaction: the consumer pays a total that includes the food cost, a delivery fee, and a service fee. The platform retains the service fee and its commission on food orders. The restaurant receives the food cost minus the commission. The courier receives the delivery fee minus any platform take rate. This three-way split requires marketplace payment infrastructure — specifically, Stripe Connect's connected account model, where both the restaurant and the courier have their own connected Stripe accounts, and the platform can initiate payouts to them on their respective schedules. Restaurant payouts are typically weekly. Courier payouts may be daily or instant depending on the market, with instant payout often available as a paid option. Stripe Connect also handles tax reporting: 1099-K forms for restaurants above IRS thresholds, and 1099 forms for couriers above earning thresholds. Standard payment processing cannot do any of this without significant custom engineering.

Mapping and Routing Platform (Google Maps Platform / Mapbox) Essential at every stage of the experience. For consumers: geocoding the delivery address they type and verifying it is serviceable by restaurants within the delivery radius. For restaurant discovery: calculating which restaurants can reach the consumer's location within a given maximum delivery time. For ETA calculation on the checkout screen: combining the estimated restaurant prep time with the driving time from restaurant to consumer address, factoring in live traffic. For couriers: turn-by-turn navigation to the restaurant pickup, then turn-by-turn navigation to the delivery address. For consumer live tracking: showing the courier's current position moving toward the delivery address. Maps are a significant cost center at food delivery scale — millions of routing and geocoding calls per day — which is why mature platforms invest in caching, batching, and in some cases in-housing parts of the routing infrastructure.

Real-Time Data Sync (Firebase Realtime Database / Pusher) Three apps must receive state updates simultaneously as an order progresses. When the consumer places the order, the restaurant tablet must update within a second. When the restaurant accepts, the consumer's tracking screen must update immediately. When the restaurant marks the order as ready, the platform dispatches a courier and the Courier App must show the new assignment in real time. When the courier picks up and begins navigating to the consumer, the consumer's live tracking activates and begins showing courier movement every few seconds. This level of real-time synchronization across three simultaneous client applications on different devices and networks is not achievable with HTTP polling under reasonable server load. Firebase Realtime Database and Pusher both provide infrastructure for persistent client connections that push state changes to subscribed clients as they happen.

Anonymized Communications (Twilio) Consumers and couriers frequently need to communicate during delivery — the courier cannot find the building entrance, the consumer's phone buzzer is broken, or a gate code is needed. This communication happens through Twilio's Proxy service: both parties message or call through a masked temporary number, so neither ever sees the other's real contact details. This protects both parties' privacy, keeps the communication observable by the platform for dispute resolution, and prevents off-platform contact that would circumvent the marketplace. Twilio also handles outbound notifications from the platform — consumer order status SMS alerts, courier assignment push backup notifications, and restaurant onboarding communications.

Restaurant POS / Order Integration (Olo / Square / Custom) For independent restaurants, the tablet app is sufficient — orders flow in and kitchen staff read them from the tablet. For chain restaurants and high-volume independents, manual tablet management does not scale. These restaurants run point-of-sale systems and kitchen display systems where orders must appear automatically, without a staff member having to re-enter them. Olo is the dominant US middleware for restaurant digital ordering integrations — it connects delivery platforms to restaurant POS systems, enabling direct order injection into the kitchen display system, real-time menu sync (so item availability in the delivery app reflects what the POS knows), and automated 86ing when the POS signals an item is out of stock. Without this integration, restaurants manually manage two order streams and make menu update errors that result in consumer disappointment.

Courier Screening Provider (Checkr / Certn) Couriers must be identity-verified before their first delivery and, in markets where they drive motor vehicles, background-checked and driving-record-checked. Checkr is the dominant US provider for gig economy courier screening. For international markets, Certn and local equivalents handle jurisdiction-specific screening requirements. The screening workflow is integrated into the courier onboarding flow: the courier submits personal information through the app, the platform initiates the check via API, and the screening provider returns a pass, fail, or manual review result that determines whether the courier account is activated. Continuous monitoring subscriptions — which automatically notify the platform of new disqualifying events on active courier accounts — are also available and used by mature platforms with strong trust and safety programs.

Operations Analytics Platform (Segment / Amplitude / Internal Data Warehouse) Three separate analytical views must coexist: consumer analytics (funnel conversion, reorder rates, cuisine preferences, LTV), restaurant analytics (order volume, prep time accuracy, cancellation rate, top items by revenue), and courier analytics (utilization, delivery time performance, zone coverage density). Segment captures events from all three applications and routes them to Amplitude for product analytics and to the data warehouse for business intelligence. Operations managers live in these dashboards — zone-level courier supply, restaurant partner performance, and consumer retention cohorts are the instruments they use to manage the marketplace.

The Three-Party Coordination Problem in Detail

The dispatch timing algorithm is the most technically demanding component of the platform, and it is entirely motivated by the three-party structure:

Step 1 — Order placement to restaurant acknowledgment. The order must reach the restaurant tablet within 1–2 seconds of placement. The restaurant has a configurable acceptance timeout (typically 2–3 minutes). If the restaurant does not acknowledge, the platform auto-accepts (for restaurants with auto-accept enabled) or cancels with a consumer refund. Slow or missed restaurant notifications are one of the highest-impact failure modes for consumer satisfaction.

Step 2 — Preparation time estimation and courier dispatch timing. The platform estimates how long the restaurant will take to prepare the order. This estimate combines: the restaurant's self-reported default prep time, historical prep time data for this restaurant and these specific items, the restaurant's current order queue load, and the time of day. The platform uses this estimate to calculate when to dispatch a courier so they arrive at the restaurant approximately when the food is ready. Dispatching 5 minutes early wastes courier time and money. Dispatching 5 minutes late makes food cold.

Step 3 — Courier selection and routing. When the dispatch moment arrives, the platform selects the optimal courier from all available couriers in the zone, considering: proximity to the restaurant, current assignment load (some platforms batch two orders per courier), historical on-time delivery rate, and estimated drive time. The selection is a real-time optimization problem run continuously as the courier fleet moves and new orders arrive.

How To Adapt It

For a grocery delivery variant, keep the three-party shape and replace:

• Restaurant with Grocery Store or Dark Store (a warehouse-only fulfillment center with no dining customers)
• Menu items with a SKU catalog with real-time inventory levels
• Preparation time with picking time — a warehouse associate assembles the order from shelves
• Add an inventory availability API so the consumer sees accurate stock levels rather than discovering items are unavailable after ordering

For a convenience delivery variant (alcohol, pharmacy, convenience stores), add an age verification integration for regulated products and a pharmacist approval step for any prescription or controlled items.

For a platform-owned fulfillment model where the platform employs couriers as employees rather than independent contractors, remove the external Courier Screening Provider — screening moves in-house — and replace the Stripe Connect payout model with payroll processing.

When To Use This Template

Use this template when you need to explain:

• why food delivery is a three-sided marketplace and what that means for the architecture compared to a simpler two-sided model
• the three-stage time-coupling between order, restaurant preparation, and courier dispatch, and why it drives dispatch algorithm complexity
• how marketplace payment infrastructure handles a three-way split that standard payment processing cannot
• why the Restaurant App is a first-class product requiring dedicated hardware, support, and POS integration work
• the real-time synchronization requirements across three simultaneous client applications on different devices and networks
• how menu data management at scale across thousands of restaurant partners becomes a significant ongoing data operations challenge