Food delivery is one of the most unforgiving product categories. Users expect instant browsing, frictionless ordering, and real-time tracking. A 2-second delay on the menu page costs conversions. A failed payment flow at checkout loses the customer permanently. A stale order status creates support tickets.

A food delivery startup approached us to build Colleatz — a modern food ordering platform connecting customers with local restaurants. The challenge was not building a food delivery app — hundreds exist. The challenge was building one that felt fast on every interaction, worked reliably on spotty mobile connections, and looked good enough that users would choose it over Swiggy and Zomato for their favorite local restaurants.

Colleatz Food delivery platforms demand sub-second performance and bulletproof reliability

Architecture Decisions

Why Next.js + FastAPI + MongoDB

Colleatz Architecture
├── Frontend: Next.js (React)
│   ├── Server-side rendering for menu pages (SEO + speed)
│   ├── Client-side state for cart and ordering flow
│   ├── Progressive Web App capabilities
│   └── Mobile-first bottom navigation
├── Backend: FastAPI (Python)
│   ├── Restaurant and menu management API
│   ├── Order processing pipeline
│   ├── Payment integration
│   └── WebSocket server for real-time updates
├── Database: MongoDB
│   ├── Restaurants and menus (flexible schema)
│   ├── Orders (document model fits order structure)
│   └── User profiles and preferences
├── Notifications: Twilio
│   ├── OTP verification
│   └── Order status SMS updates
└── Deployment
    ├── Vercel (frontend)
    └── Azure (backend services)

Why MongoDB over PostgreSQL? Food delivery data is inherently document-shaped. A restaurant has menus, menus have categories, categories have items, items have variants and add-ons. In PostgreSQL, this requires 6+ tables with complex joins. In MongoDB, it is a single document with nested arrays. Read performance is significantly better for the primary use case: loading a restaurant's full menu in one query.

Why FastAPI over Django? FastAPI's async-native design handles concurrent WebSocket connections efficiently. For a food delivery platform where hundreds of users might be tracking orders simultaneously, async performance matters. FastAPI also starts faster and uses less memory than Django, reducing infrastructure costs.

Performance Optimizations

Server-Side Rendering for Menu Pages

Menu pages are the most visited pages on any food delivery platform. We used Next.js SSR with aggressive caching:

Menu Page Performance Strategy
├── First visit: Server-side rendered (complete HTML)
│   ├── Full menu data in initial HTML (no loading spinner)
│   ├── Images lazy-loaded with blur placeholders
│   └── Time to First Contentful Paint: < 1.2 seconds
├── Subsequent visits: Client-side navigation
│   ├── React state preserved (cart persists)
│   ├── Menu data cached in SWR
│   └── Navigation feels instant (< 200ms)
└── Revalidation: ISR with 5-minute intervals
    └── Menu updates appear within 5 minutes

Smart Cart System

The cart is the highest-friction component in food delivery. Users add items, modify quantities, switch between restaurants, and often abandon mid-flow. We built a persistent cart system:

Feature Implementation
Persistence Cart stored in localStorage + server sync
Real-time pricing Prices recalculated on every modification
Restaurant switching Warning dialog when adding from different restaurant
Item customization Variants and add-ons preserved across sessions
Quick reorder One-tap reorder from order history

Real-Time Order Tracking

Once an order is placed, users expect live status updates. We implemented a WebSocket-based tracking system:

Order Status Flow
├── Order Placed → Payment confirmed
├── Accepted → Restaurant confirms order
├── Preparing → Kitchen is working on it
├── Ready → Waiting for pickup
├── Out for Delivery → Driver has the order
├── Delivered → Order complete
└── Each transition triggers:
    ├── WebSocket push to user's browser
    ├── SMS via Twilio
    └── Push notification (PWA)

The WebSocket connection uses a heartbeat mechanism to detect disconnected clients. When a user's connection drops (common on mobile networks), status updates are queued and delivered in batch upon reconnection.

Mobile-First Design

Over 80% of food delivery orders come from mobile devices. We designed mobile-first with specific optimizations:

Bottom Navigation

The primary navigation uses a bottom tab bar optimized for thumb reach:

Tab Function Interaction
Home Restaurant discovery Scroll, search
Search Find specific restaurants or dishes Keyboard input
Cart Current order Modify, checkout
Orders Order history and tracking View, reorder
Profile Settings, addresses, payment methods Manage

Touch Targets

Every interactive element meets a minimum 44x44px touch target. Add-to-cart buttons, quantity controls, and navigation elements are oversized for easy thumb interaction.

Offline Resilience

The PWA service worker caches the restaurant list, menu data, and static assets. Users can browse menus even with no network connection. When connectivity returns, any queued actions (cart modifications) sync automatically.

Twilio Integration

SMS notifications serve two purposes: OTP verification for login and order status updates.

Notification Trigger Template
Login OTP User requests login "Your Colleatz verification code is {OTP}. Valid for 10 minutes."
Order confirmed Payment success "Order #{id} confirmed. Estimated delivery: {time}"
Out for delivery Driver picks up "Your order is on its way. Track live: {url}"
Delivered Driver confirms "Order delivered. Rate your experience: {url}"

We implemented a queue-based SMS system to handle burst traffic during peak ordering hours (7-9 PM) without hitting Twilio rate limits.

Results

Metric Achievement
Time to First Contentful Paint Under 1.2 seconds
Menu page load (cached) Under 200ms
Order placement to confirmation Under 3 seconds
Cart abandonment rate 22% (industry average: 35%)
Mobile responsiveness 100% mobile-first
PWA Lighthouse score 94/100

Lessons Learned

1. MongoDB Shines for Read-Heavy Document Data

The restaurant-menu-item hierarchy maps perfectly to MongoDB's document model. A single query retrieves an entire restaurant with all menus, categories, and items. The same query in PostgreSQL would require multiple JOINs across 4-5 tables. For a read-heavy workload like menu browsing, the performance difference is measurable.

2. SSR + Client-Side Hydration Is the Right Pattern

The initial page load must be fast (SSR handles this). Subsequent interactions must be instant (client-side state handles this). This hybrid approach gave us the best of both worlds: SEO-friendly, fast first paint, and app-like interactivity after hydration.

3. WebSocket Reliability Beats WebSocket Speed

We initially focused on minimizing WebSocket latency. In practice, reliability matters far more. Users on Indian mobile networks frequently switch between WiFi and cellular. Our reconnection logic with message queuing ensured no status updates were lost, even during network transitions.

4. Progressive Web Apps Are Underrated

PWA capabilities (offline browsing, home screen installation, push notifications) gave Colleatz near-native app functionality without the App Store submission process. For a startup iterating quickly, this saved weeks of development time and eliminated the iOS/Android review cycle.

Colleatz reinforced our belief that performance is a feature, not an optimization. Every millisecond of load time translates directly to conversion rates and user satisfaction. In food delivery, where users are hungry and impatient, performance is the product.

Building an e-commerce or food delivery platform? Get in touch — we specialize in high-performance web applications.

Comments