Food Delivery App Like Zomato & DoorDash: Architecture, Features, and Scale

As Head of Tech and Client Success at Acquaint Softtech, a software product development company with 1,300+ projects delivered across 13+ years, I review food delivery platform architecture proposals every month. The majority of proposals I see describe features. Very few describe the data model that makes those features possible. This distinction matters more than any framework choice or team size decision: a food delivery app, Zomato DoorDash's architecture features scale heavily on the underlying data model. A platform built on an incorrectly designed schema cannot be fixed without a rebuild. 

The structure of the Order entity, order state machine, Restaurant, and DeliveryZone relationships, and CommissionLedger determines whether the platform can scale from 500 to 50,000 daily orders without architectural debt. This guide explains the core entities, state management, platform design decisions used by Zomato and DoorDash, and the key scaling triggers that signal when the architecture must evolve.

---

Problem: Planning a food delivery app with only features like search, cart, and tracking? What about the order data model, delivery zones, commission logic, or order status rules? Without these, the app may look good in demos but break in real-world operations.

Agitate: A wrong architecture is expensive to fix later. It means rebuilding APIs, migrating live data, and fixing operational issues while orders keep coming in. For growing platforms, this can delay scaling, increase costs, and create unreliable customer experiences.

Solution: This guide explains the core architecture behind platforms like Zomato and DoorDash, from data models and order workflows to scaling triggers, so you can build a reliable, production-ready food delivery platform from day one.

Every food delivery app feature depends on a strong underlying data model, where entities like Restaurant, PartnerLocation, and CommissionLedger power search, live tracking, and payouts. Without proper entity design, features may work individually but fail when integrated. 

The complete guide to on-demand app development in 2026 covers the platform architecture pattern that food delivery inherits. This guide goes one level deeper: the specific entities, the data model decisions, the state machine rules, and the scaling triggers that make the platform reliable at commercial scale.

For teams evaluating who builds this platform, Acquaint Softtech's MERN stack development services cover the Node.js, React, MongoDB, and Express architecture used for the food delivery data layer and API. The React Native development team handles all three mobile interfaces: the customer app, the restaurant tablet app, and the delivery partner app.

The Six Platform Entities Every Food Delivery App Is Built On

A food delivery platform has six core entities. Every feature in every interface is a read from, a write to, or a relationship between these six entities. Designing them correctly before writing code is the single highest-return pre-build activity for any food delivery platform. Getting any one of them wrong produces a constraint that becomes visible only after the platform is live and operational.

Entity	Primary Fields	Key Relationships	Design Decisions That Cannot Be Changed Later
Order	id, status, customer id, restaurant id, partner id, items, subtotal, commission, delivery fee, created at, delivered at	Belongs to Customer, Restaurant, and DeliveryPartner. Has many OrderItems. Belongs to CommissionLedger.	The status field must use an enum with a check constraint. Cannot be free text. State machine is enforced at the DB layer.
Restaurant	id, name, owner id, address, lat, lng, cuisine tags, commission rate, status, prep time avg, rating	Has many MenuItems, MenuCategories, Orders, and DeliveryZones. Belongs to CommissionLedger.	commission rate must be per-restaurant, not platform-wide. Changing this post-launch requires migration of historical payout records.
DeliveryPartner	ID, name, phone, status, lat, lng, rating, acceptance rate, current order ID	Has many PartnerLocationHistory, Orders assigned. Belongs to EarningsLedger.	lat and lng must be written to Redis, not PostgreSQL, for live dispatch queries. Storing live location in PostgreSQL only produces dispatch timeouts at scale.
MenuItem	id, restaurant id, name, description, price, category id, is available, modifiers	Belongs to Restaurant and MenuCategory. Has many OrderItems.	The availability must be a boolean updated in Redis, not only in PostgreSQL. Menu availability propagation latency exceeds 60 seconds if PostgreSQL is the only source.
DeliveryZone	id, restaurant id, polygon geometry, delivery fee, min order value, max distance	Belongs to the restaurant. Used to filter restaurant visibility in the customer app.	polygon geometry is required at scale. Radius-based zones produce irrelevant restaurant visibility. Cannot switch radius to polygon without a data migration.
CommissionLedger	id, restaurant id, order id, gross value, commission rate, commission amount, refund adjustment, settlement cycle, paid at	Belongs to Restaurant and Order.	Must be per-order from day one. A platform that aggregates commission data without per-order records cannot produce auditable payout statements for restaurant partners.

Choosing radius vs polygon DeliveryZone design early is important because scaling to multiple cities later makes migration complex and expensive. Acquaint Softtech scopes polygon geometry into the DeliveryZone entity at MVP design time for every food delivery build through the product discovery workshop services phase, regardless of whether multi-city expansion is in the initial scope.

The Order Data Model: Fields, Relationships, and the Decisions That Cannot Be Undone

The Order entity is the centre of the food delivery data model. Every other entity either writes to it, reads from it, or derives financial data from it. The specific field decisions made for the Order entity at design time determine whether the platform can produce accurate payout statements, resolve disputes with evidence, and audit delivery performance. Three decisions in the Order data model cannot be changed without a full data migration after the platform goes live.

Decision 1: Status as an Enum With a Check Constraint, Not a String

The order status field should be defined as a PostgreSQL enum with strict check constraints from the beginning. Using a free-text varchar field leads to inconsistent values like “delivered”, “Delivered”, or “completed”, which break reporting, restaurant dashboards, and commission calculations. Fixing these inconsistencies later requires complex data-cleaning migrations across the entire database. Acquaint Softtech's dedicated software development team services enforce this constraint as a code review requirement on every food delivery build from sprint one.

Decision 2: Timestamps for Every State Transition, Not Just Created and Delivered

The Order entity should store timestamps for every status change, such as restaurant notified, accepted, partner assigned, collected, delivered, and failed - not just created and delivered times. These timestamps are essential for tracking delays, resolving disputes, and monitoring SLA performance. Without them, the platform cannot properly analyze operations or investigate issues at scale.

Decision 3: Commission Rate Stored Per Order, Not Derived From the Restaurant Record

The commission rate must be stored on each Order record when the order is created, not calculated later from the Restaurant table. Otherwise, payout calculations become inaccurate whenever commission rates change before settlement. Storing the rate per order ensures accurate, auditable, and dispute-proof payout statements. Teams using Acquaint Softtech staff augmentation services can build scalable CommissionLedger systems with the right architecture from the start.

Field	Type	Populated By	Constraint Rule
id	UUID	Generated on order creation	Primary key. Cannot be null.
status	ENUM	Set by OMS on each state transition	Check constraint: valid values only. No free text.
customer id	UUID FK	Set by the auth token at order placement	Foreign key to Customers. Cannot be null.
restaurant id	UUID FK	Set by cart selection	Foreign key to Restaurants. Cannot be null.
partner id	UUID FK	Set by the dispatch engine on assignment	Nullable until assignment. Foreign key to DeliveryPartners.
items	JSONB	Set the order placement from the cart	Snapshot of items at time of order. Not a live reference.
subtotal	DECIMAL	Calculated at order placement	Cannot be null. Must match the sum of items.
commission rate	DECIMAL	Copied from the restaurant at placement time	Stored per order. Not derived at settlement.
commission amount	DECIMAL	Calculated: subtotal x commission rate	Calculated at order placement. Stored, not recomputed.
delivery fee	DECIMAL	Calculated from the DeliveryZone at placement	Stored at the placement. Not recalculated after.
restaurant notified at	TIMESTAMP	Set when the notification is dispatched	Nullable until notification is sent.
accepted at	TIMESTAMP	Set when restaurant accepts	Nullable until accepted.
partner assigned at	TIMESTAMP	Set by the dispatch engine	Nullable until partner assigned.
collected at	TIMESTAMP	Set when the partner confirms collection	Nullable until collected.
delivered at	TIMESTAMP	Set when delivery is confirmed	Nullable until delivered.
delivery address	JSONB	Snapshot from customer profile	Snapshot at placement. Not a live reference to the saved address.

The items and delivery address fields are stored as JSONB snapshots taken at the moment of order placement. They are not live foreign key references to the MenuItem or Customer address tables. This snapshot pattern is essential: if a menu item price changes after an order is placed, or a customer updates their saved address, the order record must still reflect the original data at the time of placement. 

A platform using live references would create mismatches between order history, charged price, and delivered details. Acquaint Softtech applies this snapshot pattern in its white-label software development approach for all time-sensitive order fields in food delivery builds.

The Order State Machine: 9 States, 11 Transitions, and the Rules That Keep Data Clean

A state machine is a formal system that defines every valid Order status and allowed transition in a food delivery platform. A typical delivery order includes 9 valid states and 11 approved transitions, and any invalid transition must be rejected to prevent impossible order states. Businesses can also hire AI/ML engineers through Acquaint Softtech to build smarter automation, prediction models, and operational intelligence into food delivery platforms.

Status Transition	Trigger	Action
created → restaurant notified	Payment confirmed	Restaurant receives notification via WebSocket and FCM
restaurant notified → accepted	Restaurant accepts order	OMS records acceptance and dispatch begins
restaurant notified → auto accepted	No response within 90 seconds	OMS auto accepts for high volume partners
restaurant notified → rejected	Restaurant declines order	Order rerouted or refunded
accepted → in preparation	Restaurant starts preparation	Customer notified and ETA updated
in preparation → ready for pickup	Restaurant marks order ready	Dispatch engine assigns delivery partner
ready for pickup → partner assigned	Delivery partner accepts order	Customer receives partner details
partner assigned → collected	Partner collects order	Live tracking enabled
collected → in transit	Collection confirmed	GPS tracking starts
in transit → delivered	Partner marks delivered	Earnings and commission processed
Any active state → failed	Manual override or timeout	Customer refunded and incident logg

Three transition rules deserve specific attention because violating them produces data that is impossible to reconcile without a manual database fix.

Rule 1: An order cannot transition from any state to delivered without passing through collected. A platform where the delivery partner app sends a delivered event without a prior collected event will mark orders as delivered that the partner never picked up. The check constraint that enforces this rule is a guard clause in the OMS transition handler: before writing the delivered status, the handler checks that collected at is not null. If collected at is null, the transition is rejected, and the error is logged.

Rule 2: An order cannot transition to a partner assigned without a non-null partner ID. A dispatch engine that writes the partner-assigned status before confirming the partner record exists will produce orders in an assigned state with no partner to collect them. The OMS transition handler validates that the partner ID foreign key resolves before writing the status change.

Rule 3: An order in a failed state cannot be transitioned to any other status by any system except the operations admin panel. Automated systems, the dispatch engine, the notification service, and the delivery partner app must check the current status before firing any transition event. An order that has been manually failed by the operations team must not be reassigned by the dispatch engine because the dispatch event fires after the failure event has been processed.

Platform Design Decisions: The 8 Choices Made Before Sprint One

These eight decisions shape the data model, the API design, and the mobile app architecture of a three-sided food delivery platform. Each one has a default choice that is technically simpler and a correct choice that is operationally required. The default choice is appropriate for a proof of concept, while the correct choice is required for any platform that will operate commercially.

Design Decision	Simpler Default Choice	Correct Choice for Production	Cost of Getting It Wrong
Commission rate storage	Join the restaurant table at the settlement	Store rate per Order at placement time	Incorrect payouts on every commission rate change. Manual reconciliation.
Menu availability state	Boolean in PostgreSQL. Polled on page load.	Boolean in Redis. Pushed to the customer app via WebSocket.	60-second to 5-minute lag. 8-12% rejection rate on sold-out items.
Delivery zone geometry	Radius in km from restaurant lat and lng	Polygon geometry stored in the PostGIS extension field	Cannot support dense urban multi-city expansion. Full migration required.
Driver location storage	lat and lng columns in the DeliveryPartner table in PostgreSQL	GEOADD in Redis. PostgreSQL is only for the location history log.	Dispatch engine timeouts at 500+ active partners.
Order item storage	Foreign key references to MenuItem records	JSONB snapshot of item data at order creation time	Price changes affect historical order records. Dispute resolution fails.
Commission ledger	Weekly export from the order table to the spreadsheet	Per-order CommissionLedger record created at delivery confirmation	Cannot scale past 200 restaurant partners without full-time reconciliation staff.
Notification architecture	WebSocket push only	WebSocket primary, FCM secondary, SMS or call tertiary	2-5% notification failure. 20-50 missed restaurant order alerts per day at 1,000 orders.
Settlement trigger	Manual: The finance team runs the settlement script weekly	Automated: nightly job creates settlement batch. Finance approves.	Finance team bottleneck. Settlement delays generate partner disputes.

 The commission rate storage decision and the order item storage decision are the two that produce the most invisible damage. Both work correctly in development and in the first weeks of production. Both fail silently as the platform ages: commission rates change, menu prices change, and historical order records start producing incorrect numbers. The failures surface first in restaurant payout disputes, where the restaurant's calculation of what they are owed does not match the platform's calculation. 

Resolving these disputes without per-order commission and item snapshots requires manual cross-referencing of order logs, menu change history, and commission rate change history, work that consumes operations time and erodes restaurant partner trust. Acquaint Softtech's software product development services include a pre-build data model review that explicitly checks for these two patterns in every food delivery specification before development begins.

How Zomato and DoorDash Handle Peak Load: Queue Design and Concurrency Patterns

A food delivery platform handling around 1,000 daily orders typically sees peak load during lunch (12:00–14:00) and dinner (19:00–21:00), when 65% to 75% of all orders are placed. This surge can reach 3 to 5 times the average per-minute traffic. Platforms like how Zomato and DoorDash work are built specifically to handle these spikes using scalable queue systems and distributed architecture. 

The systems that fail under this peak load, and the queue design patterns that prevent those failures, determine whether the platform performs smoothly during high demand or suffers missed orders and customer complaints exactly when usage is highest.

The Order Placement Queue

Order placement should use asynchronous processing, where the HTTP request only handles payment, saves the order, publishes an event to Kafka or RabbitMQ, and quickly returns the order ID. Tasks like restaurant notification, commission calculation, and dispatching run separately through event consumers, keeping response times under 2 seconds even during peak load.

The Dispatch Assignment Queue

The dispatch engine is a critical high-load component that can fail under peak demand because it must track active orders, available partners, and pending assignments in real time. A scalable design makes it stateless and event-driven, consuming from a ready-for-pickup queue. Each event is processed independently by reading partner availability from Redis, scoring and assigning a driver, sending notifications, and updating the order management system. This stateless approach allows horizontal scaling behind a load balancer to handle peak traffic efficiently.

A dispatch engine that maintains in-memory assignment state, tracking which orders are in flight and which partners are assigned, cannot scale horizontally and will saturate at 200 to 300 concurrent dispatch operations. Acquaint Softtech's DevOps engineering team configures Kubernetes horizontal pod autoscaling for the dispatch service, triggered by queue depth metrics, so the dispatch tier scales automatically during peak hours without manual intervention.

The Notification Delivery Queue

Restaurant notifications are handled by a dedicated service consuming events from a restaurant-notified queue. It first attempts delivery via WebSocket, then falls back to FCM push notifications, and if there is no acknowledgment within 30 seconds, it escalates to SMS or automated calls via Twilio. 

Every attempt is logged with timestamps and response codes, and the system uses a retry budget of 3 attempts with exponential backoff. This ensures most restaurants receive notifications within 90 seconds of order placement (around 97%–99% reliability), whereas systems without retries fail immediately on the first error with no recovery path.

System	Architecture Target	Failure Without Proper Architecture
Order Placement API	Under 2s response during peak traffic	Slow checkout and high customer abandonment
Dispatch Engine	Stateless horizontal scaling	Dispatch failures during peak load
Restaurant Notifications	Multi layer retry system	Missed restaurant alerts
GPS Location Writes	Redis GEOADD based tracking	Database contention and map failures
Customer WebSocket Connections	Horizontal Socket.IO scaling	Live tracking stops updating

The Six Scaling Triggers: When to Upgrade Each Platform Component

A food delivery platform does not need enterprise-grade infrastructure on day one. It needs infrastructure that is sufficient for the current order volume and can be upgraded to the next threshold without a rebuild. The six triggers below are the observable conditions that tell an engineering team that a specific component has reached its current capacity and must be upgraded. 

Each trigger has a specific metric and a specific upgrade action. Acquaint Softtech monitors these triggers in all production food delivery platforms maintained under ongoing software support and maintenance services, with automated alerts configured for each threshold.

Trigger	Threshold	Upgrade Action
PostgreSQL write saturation	API response time above 500 ms	Add read replica and shift reporting queries
Redis memory pressure	Memory usage above 70%	Deploy Redis cluster and separate workloads
Dispatch engine queue depth	More than 50 pending events	Add dispatch service instances with Kafka scaling
WebSocket connection load	More than 5,000 active connections	Scale WebSocket servers with Redis adapter
Notification failure rate	Above 1% failed notifications	Add fallback SMS layer and monitor failures
Commission reconciliation delays	Batch job exceeds 30 minutes	Move settlement processing to

Each of these upgrade actions is a configuration or deployment change, not a code change. A food delivery platform or restaurant aggregator design built with the correct initial architecture — stateless dispatch, Redis for geospatial and session data, Socket.IO with a Redis adapter, per-order CommissionLedger records — can scale from 500 to 50,000 daily orders by executing the upgrade actions above in sequence as each trigger is observed. A platform built without the correct initial architecture cannot execute these upgrades without modifying the application code and migrating production data.

What Does Building a Food Delivery App Cost in 2026?

All figures below reflect builds that include the complete data model design described in this guide: the six platform entities correctly structured, the Order state machine enforced at the database layer, the eight platform design decisions made correctly, the peak load queue architecture in place from sprint one, and the scaling trigger monitoring configured before launch. 

A build that omits any of these components may cost less at the quote stage and will cost significantly more at the first operational failure. All figures reflect Acquaint Softtech's offshore delivery rates from India. The 40% cost saving against in-house team costs is consistent across food delivery engagements documented in Acquaint Softtech's dedicated development team pricing model.

Build Tier	Build Cost	In-House Equivalent	Timeline	Team Size
MVP: 1 city, restaurant-managed delivery, all 6 entities, full state machine	$28,000 to $50,000	$100,000 to $155,000	14 to 20 weeks	4 to 6 devs
Growth: platform-managed delivery, scoring dispatch, CommissionLedger, analytics	$55,000 to $95,000	$185,000 to $290,000	24 to 36 weeks	7 to 10 devs
Scale: multi-city PostGIS zones, ML dispatch, subscription memberships, ad engine	$95,000 to $160,000	$310,000 to $490,000	34 to 50 weeks	11 to 16 devs
Enterprise: 10+ cities, full fintech settlement layer, multi-market payments	$160,000 to $260,000	$530,000 to $800,000	50 to 70 weeks	17 to 24 devs

What the Monthly Rate Includes at Acquaint Softtech

Data model and architecture:  Platform entity design review, state machine specification, PostgreSQL schema with enum constraints, Redis geospatial index configuration, and PostGIS delivery zone setup

Backend services:  OMS API in Node.js or Python, Django REST Framework, dispatch engine as a stateless Kafka consumer, notification service with three-layer retry, CommissionLedger settlement service

Mobile apps:  React Native customer app (iOS and Android), React Native delivery partner app, React web restaurant operations portal - all consuming the shared API

Admin panel:  Operations live map with order queue management, support dispute resolution with state history and GPS route replay, and finance commission reconciliation dashboard

Infrastructure via DevOps:  Kubernetes cluster with horizontal pod autoscaling for dispatch and WebSocket services, Redis cluster configuration, CI/CD pipeline, staging, and production environments

QA coverage:  State machine transition testing, commission calculation accuracy validation, notification delivery reliability testing, GPS tracking under low-connectivity conditions, peak load simulation

Ownership:  100% source code ownership from the first commit. No platform licensing. No lock-in to Acquaint Softtech for hosting or maintenance.

The rate the client pays is the rate. No employer overhead, equipment costs, or hosting costs are added on top. Acquaint Softtech deploys the first developer within 48 hours of client team approval. For clients who need to validate the data model and platform design before committing to a full build, Acquaint Softtech's MVP development services allow the platform entity design, the state machine specification, and the MVP build to be completed as a phased engagement before the growth-stage scope is committed.

Frequently Asked Questions