Colleatz Food Delivery Platform: A Performance Case Study

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.

Food delivery platforms demand sub-second performance and bulletproof reliability

Architecture Decisions

We built Colleatz on Next.js for the frontend, FastAPI for the backend, and MongoDB for the database, deployed on Vercel and Azure. This stack gave us server-side rendered menu pages for speed and SEO, async WebSocket support for real-time order tracking, and a document model that matches food delivery’s nested restaurant-menu-item structure.

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, a tradeoff we break down in more depth in our Django REST Framework vs. FastAPI comparison. 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, weighing the tradeoffs covered in our server-sent events vs. WebSockets guide before committing to bidirectional sockets:

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), the same ones we cover in our guide to progressive web apps, 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.