Design Swiggy/Zomato Food Ordering Frontend
Designing a geolocation-centric restaurant discovery app with real-time cart calculations, menu customizers, and live order tracking.
1. Problem Statement
Design a geolocation-aware food delivery web portal loading menus, updating carts optimistically, and animating live delivery tracker maps.
2. Business Context & User Friction
Food delivery systems suffer from low conversion margins. A slow geolocation startup or lost cart inputs cause immediate booking dropouts.
3. Requirements Matrix
Functional Requirements
- Detect user geolocations coordinates to query nearby open restaurants lists.
- Display restaurant menus with customized food selection sheets.
- Track ongoing deliveries coordinates in real-time.
Non-Functional Requirements
Performance
- Startup geolocation menus resolve under 1.5s.
- Instant optimistic cart addition feedback (<50ms).
- Optimized map layers rendering pipelines.
Scalability
- Support millions of concurrent live coordinate streams.
- Isolate menu page size distributions.
Accessibility (a11y)
- Dynamic aria-live announcements for cart changes.
- Keyboard focus navigation inside customization panels.
Security
- Encrypt users GPS coordinates data entries.
- Authorize checkout prices on backend API gates.
Reliability & Failover
- Automatic fallback to polling if WebSocket connections fail.
- Local storage backup of active cart items.
Observability
- Track geolocation resolution failures.
- Measure map rendering FPS and socket latency statistics.
4. Core User Flows
Ordering food with customization
- App resolves user geolocation, showing nearby restaurants.
- User clicks restaurant, opening dynamic category menus.
- User clicks Add Food, opening customized drawer checkboxes.
- User checks custom addons; cart updates optimistically.
- Checkout routes to live order tracking map.
5. High-Level Design & Layers
The architecture combines a static restaurant catalog display with a localized client state cart (Zustand) and a WebSocket order tracker.
Frontend Layers
- UI Layer: NavigationHeader, RestaurantListing, CartTray, MapCanvas.
- State Layer: Local cart Zustand store, real-time WebSocket state.
- Service Layer: Geolocation resolver, Google Maps wrapper APIs.
Major Components
- GeolocationNavbar: Triggers browser location lookups, matching coordinates to address strings.
- LiveOrderTracker: Subscribes to sockets channels, animating delivery route pins.
Data Flow Pipelines
- 1. Navbar fetches browser geolocation coordinates.
- 2. App queries matching restaurants indexes.
- 3. User actions update Zustand cart values.
- 4. WebSocket feeds coordinates to LiveOrderTracker.
6. Component Architecture & State Boundaries
| Component | Responsibility | State Owned | Dependencies |
|---|---|---|---|
| PortalShell | Coordinates geolocation lookups, cart items summaries, and maps displays. | Cart object, map pins | GeolocationNavbar, LiveOrderTracker |
7. State Management
Local UI State
- Customizer sheet inputs
- Active filter tabs
Server Query Cache State
- Geocoded address labels
- Nearby restaurants grids list
Global/Shared State
- Active cart records
- Payment tokens info
Real-Time & Sync State
- Real-time delivery driver coordinates
8. API Contracts Design
Purpose: Fetch nearby restaurants based on coordinates.
{
"restaurants": [
{
"id": "r1",
"name": "Pizza Club",
"lat": 12.9,
"lng": 77.5
}
]
}9. Caching Strategy
Browser/HTTP Cache
- IndexedDB stores active cart layouts.
- Local storage caches location addresses.
Edge CDN Caching
- Menu details caching on edge servers.
- Restaurant images compression caching near clients.
Application Cache
- Local state caching of resolved nearby listings.
Invalidation Policies
- Clear menu caches if stock indicators alter.
10. System Strategies Checklist
Performance Strategy & Budgets
- Lazy load maps API libraries until checkouts mount.
- Optimistically update cart item counts in UI before API returns.
- Avoid heavy canvas map re-renders on minor coordinate updates.
Inclusive Accessibility Design
- Screen readers announce cart updates using aria-live.
- Close customization panels using Escape key listener.
Security Safeguards & Risks
- Prune coordinates data payloads before telemetry logs.
- Enforce CSRF protection on order bookings APIs.
Telemetry & Production Observability
- Measure geolocation failures rates.
- Log order tracking socket drop ratios.
Graceful Failure & Resilience
- Let users enter address strings manually if GPS fails.
- Gracefully degrade tracker maps to simple text logs if connection drops.
Deployment, Rollout & CDN topologies
- CSR layouts backed by Edge routing setups.
- Dynamic data fetching using client libraries.
11. Architectural Decisions & Tradeoffs
Decision: Zustand local cart persistence vs server-side cart database
Instant offline cart operations without API latency.
Risks cart mismatch if menu prices update mid-checkout.
12. Interview Answer Framework
How to structure your defense of this architecture during a 45-minute technical system design session:
Explain that food delivery apps require fast initial geo-lookups and resilient carts. Outline how to coordinate geolocation APIs with restaurant menus databases.
- Do we need offline support for cart items?
- Should we show live driver movements on map screens?
Propose an AppShell linking GeolocationNavbar, menu listings, customizers, and order tracking maps.
- Explain how client cart state (Zustand) is kept in sync with local storage.
- Detail WebSocket coordinates updates throttling.
Conclude with reliability compromises (WebSockets versus polling fallback pipelines).
13. Common Pitfalls & Extension Questions
Candidate Mistakes to Avoid
- Blocking menu page loads while browser GPS coordinates resolve, causing page load lag.
- Annuallizing canvas maps on every minor driver coordinate feed, triggering UI thread freezes.
Interviewer Follow-ups / Extensions
- How would you resolve cart merge conflicts when a user updates carts across desktop and mobile concurrently?
- How do you optimize map tiles loading speeds over slow networks?