Multi-Platform Food Delivery App

Multi-Platform Food Delivery App overview

This multi-platform food delivery app is a native Android and iOS product backed by a containerised microservices platform that we designed and built from scratch. The brief was a delivery ecosystem that does not slow down, lose track of couriers or run up operating costs when large numbers of users browse menus, order meals and watch deliveries at the same time. The scope covered the two mobile clients, a unified API gateway, streaming data pipelines for courier location, an order service, a tracking service, a recommendation service, a payment gateway abstraction and a backend container mesh distributed across AWS and Azure.

Every microservice owns its own isolated data store rather than sharing a monolithic database, and every structural element, from network to cluster to storage, is defined in declarative Terraform files, so staging and production are identical and the whole environment can be rebuilt in either cloud within minutes.

Challenge in F&B operations

Legacy delivery applications share a set of failure modes: fragile data connections, slow message routing and database locking when order, tracking and browsing traffic all hit the same relational store. Courier tracking built on repeated database polling degrades exactly when demand peaks, delivery estimates based on straight-line distance are wrong at lunch and dinner, and payment flows that touch card data pull the whole platform into compliance scope.

The platform had to stay responsive through sudden transactional spikes such as national holidays or bad weather, give customers sub-second courier positions and realistic arrival times, personalise menus without slowing order placement, and meet SOC 2 Type II, GDPR and HIPAA requirements for personal and payment data.

Solution architecture & delivery

Mobile clients connect over TLS 1.3, HTTPS and WebSockets to an API gateway built on Envoy and the NGINX Ingress Controller, which handles rate limiting, TLS termination and input validation. Behind it, the order service writes to its own PostgreSQL cluster, the tracking service consumes Apache Kafka streams and maintains a Redis geospatial cache, and the recommendation service works from a separate MongoDB and Cassandra analytics store. Everything runs as Docker containers on Kubernetes, with primary workloads in AWS virtual private clouds and replica nodes, logging archives and analytical systems in Azure, linked by secure virtual networks with continuous replication so traffic can shift between providers.

Tracking is event-driven rather than polled. Courier apps capture GPS coordinates at regular intervals and send them over lightweight transport to edge servers, which publish them to Kafka topics keyed by order ID and geographical zone. The tracking microservice consumes those streams and updates Redis using geospatial index keys, so proximity and distance queries never hit disk. When a customer opens the app, a persistent connection to the notification nodes pushes each new position, producing smooth courier movement on the map. Delivery estimates come from a predictive framework running inside the cluster that combines live traffic data from mapping services with each restaurant's historical preparation times by dish and time of day, the courier's transport type and current pickup delays, and revises the estimate as conditions change.

Personalisation runs off the critical path. An asynchronous recommendation service aggregates interaction logs, order history, saved dietary preferences and time of day, computes restaurant and menu suggestions per profile and writes them to Redis, so the app shows a personalised menu at login without the analysis touching the transactional databases. The native clients, Kotlin on Android and Swift on iOS, use a dynamic layout mechanism: on authentication they download a lightweight configuration that dictates section order, highlighted local discounts and menu categories, so layouts, banners and listings change server-side without an app store release. Menu images, descriptions and price tables are cached on the device to cut data usage and keep browsing usable on weak cellular networks. Order state changes and promotions go out through Firebase Cloud Messaging and Apple Push Notifications.

Checkout goes through a payment abstraction layer that standardises communication with banks, card processors and digital wallets and fails over automatically to an alternative gateway if one network is down. Card fields are encrypted on the device with the payment provider's public keys before transmission; the backend stores only randomised reference tokens, never primary account numbers or security codes. Internally, a zero-trust service mesh requires mutual TLS between microservices, Okta enforces multi-factor authentication for employees, restaurant managers and delivery partners on every console and portal, and CrowdStrike Falcon agents run on every Kubernetes worker node. Personally identifiable information is stored separately from transactional logs and encrypted with keys held in cloud hardware security vaults; administrative tools handle deletion and export requests, and log anonymisation strips identifiers from errors and analytics records.

Operations are automated end to end. Prometheus collects CPU, memory, network error and connection-queue metrics from every container into Grafana dashboards with alert thresholds. Kubernetes autoscaling adds order-processing and menu-browsing containers as request volume climbs into lunch and dinner peaks and removes them afterwards. PostgreSQL runs a primary with read replicas across availability zones and promotes a replica within seconds if the primary fails, beneath the application layer so carts and checkouts continue. Releases use canary and blue-green patterns, routing a small fraction of traffic to the new version and shifting fully only when error rates hold.

Key features of the Multi-Platform Food Delivery App

• Native Android (Kotlin) and iOS (Swift) customer apps sharing one API gateway, security wrapper and token lifecycle
• Event-driven courier tracking on Apache Kafka and Redis geospatial indexes with WebSocket push for sub-second map updates
• Predictive delivery estimates combining live traffic, per-restaurant preparation history, courier transport type and pickup delays
• Asynchronous recommendation service that personalises restaurants and menus from order history and dietary preferences
• Server-driven dynamic layouts that reorder sections, banners and categories without an app store update
• Payment abstraction layer with multi-gateway failover, on-device field-level encryption and token-only storage
• Restaurant dashboard feeding preparation metrics, plus Firebase Cloud Messaging and Apple Push Notifications for order states and promotions
• Multi-cloud AWS and Azure deployment with Terraform, Kubernetes self-healing and canary and blue-green releases

Who this platform is for

Food delivery operators and restaurant groups that need customer, courier and restaurant-facing software able to hold up through mealtime peaks and weather-driven surges: product teams who want to change app layouts and promotions without shipping releases, operations teams who need accurate ETAs and live courier positions, and finance and compliance leads who need card data kept out of the platform entirely.

Impact & results

• Database polling for courier location replaced by a Kafka and Redis streaming pipeline delivering sub-second map updates
• Straight-line ETAs replaced by estimates that account for live traffic, restaurant preparation history and courier transport type
• No raw card numbers or security codes stored anywhere in the platform; checkout continues through an alternate gateway if one processor fails
• Layout, banner and menu changes ship server-side, removing the app store update cycle for merchandising
• On-device caching keeps menus browsable on weak cellular connections and reduces data usage
• Zero-downtime canary and blue-green releases, database failover within seconds and mealtime autoscaling

FAQ about the Multi-Platform Food Delivery App