System Design of Foodpanda

How to Build a Scalable Food Delivery App

Foodpanda Microservice Structure

Food delivery apps look simple on the outside. You tap a few buttons, and food arrives at your door. But behind that tap is one of the most complex distributed systems in modern software. This article breaks down how Foodpanda works at scale and, more importantly, what this means for you as a TPM or Agile practitioner managing the teams that build it.

1. Understanding the Foodpanda Business Model

Three-Sided Marketplace Architecture

Most marketplaces connect two groups: buyers and sellers. Foodpanda connects three: customers, restaurants, and riders. This is called a three-sided marketplace. Each side has different needs and different technical requirements. When one side grows, it must not slow down the others.

Three sided Foodpanda marketplace

TPM VIEW

As a TPM, you are not just managing features — you are managing dependencies across three product lines at once. Backlog grooming must account for how a change in the rider app affects restaurant ops and customer ETA promises.

Think of it this way: a customer places an order, a restaurant prepares it, and a rider delivers it. All three must happen in near real-time. The system must coordinate them without them ever meeting in a shared codebase.

Revenue Streams (Commission, Delivery Fee, Ads, Subscription)

Revenue Streams

2. Core Components of a Food Delivery Ecosystem

Four applications are running at the same time. Each is a separate product with its own team, backlog, and release cycle.

Customer Application

This is the app most people know. The customer browses restaurants, adds items to a cart, pays, and tracks their order live. This surface has the highest traffic and must handle spikes during lunch and dinner rushes without going down.

Restaurant Dashboard

Restaurants use a tablet or web dashboard to accept orders, manage menus, and track daily sales. When an order arrives, the restaurant gets an audio alert and a visible notification. If they miss it, the order auto-cancels after a timeout — and that failure must be logged, escalated, and reported.

Rider / Driver Application

Riders use a separate mobile app to receive delivery assignments, navigate to the restaurant, pick up the order, and navigate to the customer. The app must work with weak GPS signals and low data. Every ping from the rider app updates the live map that the customer sees.

Admin Control Panel

Operations teams use an internal dashboard to monitor order health, manage restaurant onboarding, handle refunds, and run campaigns. This tool sees less traffic but is business-critical — a broken refund flow can cascade into a customer service crisis.

TPM VIEW

Each of these four surfaces is a separate product team in most large-scale organisations. As a TPM, your role is to align cross-team dependencies — for example, the customer app cannot launch a new payment method without changes in the payment service, which affects the admin panel’s reconciliation view.

3. Functional Requirements of a Foodpanda-Like App

User Registration and Authentication

Users sign up via email, phone OTP, or social login (Google, Facebook). The system must handle token refresh, session expiry, and multi-device login. Authentication is handled by a dedicated Auth Service using JWT tokens with short-lived access and long-lived refresh tokens.

Restaurant Discovery

When a customer opens the app, they see restaurants near them. The system uses its GPS coordinates to query a geospatial index and returns results sorted by proximity, rating, and delivery time. This is where Quadtrees come in — more on that in Section 6.

Menu Management

Restaurants update menus in real time. An item going out of stock must be reflected in the customer app within seconds. Menu data is cached but must support cache invalidation when changes occur. The restaurant dashboard writes to the Menu Service, which pushes updates to the CDN cache.

Cart and Checkout

Adding items to a cart seems simple, but it requires concurrent write protection (two users adding the last item), pricing validation at checkout (prices may change between cart and payment), and idempotent payment processing (no double charges if the network drops).

Order Tracking

After payment, the customer sees a live map with the rider moving in real time. This requires a WebSocket connection from the customer app to the backend, with the rider app pushing GPS updates every 5 seconds. The system must handle thousands of concurrent active orders.

Ratings and Reviews

After delivery, customers rate the restaurant and rider. This data feeds into ranking algorithms, surfacing high-rated restaurants and deactivating underperforming riders. The pipeline runs async — ratings are written to a queue and processed in the background.

PRO TIP

Sprint planning tip: Break down Order Tracking into three separate user stories — rider pickup confirmation, live GPS stream, and delivery confirmation. Each has separate acceptance criteria and can be shipped independently.

4. High-Level System Design Architecture

Frontend Layer

All four apps (customer, restaurant, rider, admin) talk to the backend through APIs. The customer and rider apps are mobile-first (React Native or Flutter). The restaurant dashboard and admin panel are web-based (React). Each sends HTTPS requests to the API Gateway.

API Gateway

The API Gateway is the single entry point for all client requests. It handles authentication token validation, rate limiting, request routing to the right microservice, and SSL termination. Think of it as the front desk of a large office — it checks your badge before letting you through.

Microservices Layer

Behind the API Gateway are independent services: User Service, Restaurant Service, Order Service, Payment Service, Notification Service, Tracking Service, and Search Service. Each service has its own database and communicates with others via events or direct API calls.

TECH NOTE

Key design principle: Each microservice owns its data. No service reads another service’s database directly. This is called database-per-service pattern, and it prevents tight coupling that would break deployments.

Database Layer

Different data needs different storage. User profiles live in PostgreSQL. Restaurant menus in MongoDB (flexible schema). Session data in Redis. Geospatial queries in PostGIS or Elasticsearch with geo-indexing. Time-series order metrics in InfluxDB or Cassandra.

External Integrations

Foodpanda integrates with payment gateways (Stripe, local providers), Google Maps for routing, Firebase for push notifications, SMS providers for OTP, and fraud detection APIs. These integrations are abstracted behind internal wrapper services so that swapping providers does not require changes in core business logic.

5. Database Design and Data Models

Database Design and Data Model

User Database

User records include profile data, saved addresses, payment methods (tokenised, not raw card numbers), and order history references. Passwords are stored as bcrypt hashes — never in plain text.

Restaurant Database

Each restaurant document includes its menu as a nested array. This allows flexible per-restaurant customisation (modifiers, combo options, dietary tags) without rigid table schemas. Elasticsearch indexes restaurant data for fast full-text search and geospatial filtering.

Order Database

Orders have a lifecycle status: CREATED > CONFIRMED > PREPARING > PICKED_UP > DELIVERED (or CANCELLED). Each state transition is logged with a timestamp. This audit trail is critical for customer support and refund decisions.

Delivery Database

Rider locations are written every 5 seconds — this creates millions of writes per hour. Cassandra handles this with its append-friendly architecture. Only the latest location per rider is kept in Redis for fast lookup by the tracking service.

Payment Records

Every payment attempt is logged — success and failure. Idempotency keys prevent double charges. The payment service stores a reference to the external payment provider’s transaction ID so disputes can be traced end-to-end.

TPM VIEW

Data modelling decisions affect sprint velocity. If the team chooses MongoDB for orders but the finance team needs SQL-level reporting, you will spend sprints building data pipelines. Push the team to define data consumers before choosing storage.

6. Real-Time Order Tracking System Design

Realtime Order Tracking

GPS Tracking Flow

When a rider picks up an order, their app begins sending GPS coordinates every 4 to 5 seconds. These coordinates go to the Location Service via a persistent WebSocket connection. The Location Service writes the update to Redis (for instant lookup) and publishes it to a Kafka topic. The Tracking Service consumes from Kafka and pushes the update to the customer’s open WebSocket.

WebSockets vs Polling

Polling means the app asks the server every few seconds: “Anything new?” WebSockets keep a connection open, and the server pushes updates as they happen. For real-time tracking, WebSockets win — they are faster, use less bandwidth, and feel instant. Polling is simpler to implement but creates unnecessary load at scale.

TECH NOTE

At 1 million active orders, polling at 5-second intervals = 200,000 requests per second to your tracking endpoint. WebSockets handle this with persistent connections — far more efficient at scale.

Live ETA Calculation

ETA is not static. It updates as the rider moves. The system recalculates ETA using the rider’s current GPS position, current traffic conditions (from Google Maps or HERE Maps API), and the estimated restaurant prep time. The formula is: ETA = prep_time_remaining + travel_time_to_restaurant + travel_time_to_customer.

Rider Location Updates and Geospatial Indexing with Quadtrees

How does the system find available riders near a restaurant when an order is placed? It uses geospatial indexing. The most efficient structure for this is a Quadtree.

A Quadtree divides a map into four quadrants. Each quadrant divides further if it contains too many riders. When the system needs to find riders within 3 km of a restaurant, it queries only the relevant quadrant — not the entire map. This makes search logarithmic in time, not linear.

Quadtree Geospatial

TPM VIEW

Quadtrees are a backend architecture decision, but TPMs feel the impact: they determine how fast rider assignment happens after an order is placed. If this system is slow, customer satisfaction drops. Track the metric ‘time to rider assignment’ as a KPI in your sprint reviews.

7. Scaling Foodpanda for Millions of Orders

Load Balancers

A load balancer distributes incoming requests across multiple server instances. When traffic spikes at 12:30 PM (lunch rush), the load balancer ensures no single server is overwhelmed. AWS ALB (Application Load Balancer) or NGINX is a common choice. Auto-scaling groups spin up new instances automatically when CPU crosses a threshold.

Caching with Redis

Redis stores data in memory — it is 10 to 100 times faster than reading from a database. Foodpanda uses Redis to cache restaurant listings per city, menu data, active rider locations, user session tokens, and promotional banners. Cache expiry (TTL) must be tuned carefully: stale menus hurt UX; stale rider locations hurt tracking accuracy.

Database Sharding

A single PostgreSQL instance cannot handle millions of orders per day. Sharding splits the database horizontally — orders for city A go to Shard 1, orders for city B go to Shard 2. This distributes both read and write load. The challenge is cross-shard queries (e.g., a report across all cities) — these require an aggregation layer or a data warehouse like BigQuery or Redshift.

CDN Usage

Restaurant images, app assets, and static content are served from a CDN (Content Delivery Network) like Cloudflare or AWS CloudFront. The CDN caches content at edge nodes close to the user’s location — a customer in Lahore gets images from a nearby edge node, not from a server in Singapore. This cuts page load time by 60 to 80 percent.

Message Queues (Kafka / RabbitMQ)

When a customer places an order, the Order Service does not directly call the Restaurant Service, Notification Service, and Payment Service all at once. It writes an event to Kafka: ‘OrderPlaced.’ Each downstream service consumes this event independently and at its own pace. This decoupling means that if the Notification Service goes down, orders still process — notifications just catch up later.

8. Technology Stack Required to Build Foodpanda

Technology stacks

TPM VIEW

Technology decisions are not purely engineering decisions — they carry hiring, cost, and timeline implications. As a TPM, you must ensure the tech stack is documented in the Program Increment (PI) plan and that the team has capacity to build expertise, not just implement features.

9. Security, Payments, and Compliance

Authentication and Authorization

Every API request carries a JWT token. The API Gateway validates it before routing. Role-based access control (RBAC) ensures that a restaurant admin cannot access another restaurant’s data, and a rider cannot see customer payment details. OAuth 2.0 handles third-party login flows.

Payment Gateway Security

Foodpanda never stores raw card numbers. Payments are tokenised — the card is vaulted by the payment provider (e.g., Stripe), and Foodpanda stores only a token. PCI DSS compliance is mandatory for handling card data. All payment traffic uses TLS 1.2 or higher with certificate pinning in the mobile app.

Fraud Prevention

Common fraud patterns include fake accounts claiming first-order discounts, stolen cards used for large orders, and riders marking deliveries complete without delivery. The system uses rule-based fraud scoring (IP velocity, device fingerprinting, order value anomalies) plus ML models that flag suspicious patterns for human review.

Data Privacy Compliance

Depending on the operating country, Foodpanda must comply with GDPR (Europe), PDPA (Thailand/Pakistan), or other local data privacy laws. This means customer data must be deletable on request, location data must not be retained beyond a defined period, and data processing must be consented to explicitly.

PRO TIP

Security stories are often left out of product backlogs until an incident happens. Build a security checklist into your team’s definition of done: token validation, input sanitisation, rate limiting, and audit logging should be standard on every API endpoint story.

10. Development Timeline and Future Enhancements

AI Recommendations

Modern food delivery apps use collaborative filtering and content-based filtering to personalise the home screen. ‘You ordered biryani on Friday twice — here are biryani restaurants near you.’ These models run offline (batch training on order history) and are served via a low-latency feature store. The recommendation engine is a separate service that plugs into the Search Service response.

Predictive Delivery and Route Optimization

The next frontier is predicting demand before it happens. By analysing historical order patterns, weather data, local events (cricket match, Friday prayer times), and day-of-week trends, the system pre-positions riders in zones where demand is likely to spike. This is called predictive dispatch. Route optimisation uses algorithms like Dijkstra or A* enhanced with real-time traffic data to give riders the fastest path, not just the shortest one.

TPM VIEW

AI features require a different kind of backlog management. Models need labelled training data, which means data engineering stories must precede ML model stories. In SAFe terms, enabler stories for data pipelines must be planned at least one PI before the feature can ship.

Key Takeaways for TPMs and Agile Practitioners

1. Three-sided marketplaces require three aligned product backlogs — customer, restaurant, and rider — with a shared dependency board.

2. Real-time tracking is not one feature. It is a pipeline: GPS capture, event streaming, WebSocket push, and ETA recalculation — each a separate story.

3. Geospatial indexing (Quadtrees) determines how fast riders are matched to orders. Track ‘time to rider assignment’ as a measurable KPI.

4. Tech stack decisions (Kafka, Redis, Cassandra) have sprint implications — include infrastructure enabler stories in PI Planning.

5. Security and compliance are not phases — they are definitions of done. Build them into every story, not into a separate backlog.

6. AI features need data pipeline enablers planned one PI in advance.