Have you ever wondered what happens behind the scenes when you order food on apps like Zomato or Swiggy?

Several microservices work together — some talk synchronously, others asynchronously — to ensure your biryani gets delivered hot and fast! 🍛

Let's dive into the entire journey. 🚀


🛒 Step 1: User Browses Restaurants and Selects Food

🔥 Services involved:

  • Restaurant Service
  • Menu Service
  • Search Service
  • User Profile Service

📞 Communication:

  • User App → Search Service: (Sync, REST API) to search restaurants.
  • User App → Menu Service: (Sync, REST API) to fetch restaurant menus.
  • User App → User Profile Service: (Sync, REST API) to fetch saved addresses.

✅ Why synchronous?

  • User expects immediate search results and menu listing.
  • UX needs to be fast and smooth.

🧺 Step 2: Add Food Items to Cart

🔥 Services involved:

  • Cart Service

📞 Communication:

  • User App → Cart Service: (Sync, REST API) to add items or view cart.

✅ Why synchronous?

  • Real-time feedback needed when user adds/removes dishes.

💳 Step 3: Place Order and Make Payment

🔥 Services involved:

  • Order Service
  • Payment Service
  • Coupon/Discount Service

📞 Communication:

  • User App → Coupon Service: (Sync, REST API) to validate discounts.
  • User App → Payment Service: (Sync, REST API) to process payment.
  • User App → Order Service: (Sync, REST API) to place the order.

✅ Why synchronous?

  • Payments and coupons must be validated instantly to complete order.

🍳 Step 4: Restaurant Accepts the Order

🔥 Services involved:

  • Restaurant Management Service
  • Order Service
  • Notification Service

📩 Communication:

  • Order Service → Restaurant Management Service: (Async, Kafka event NEW_ORDER_PLACED) to notify restaurant.

  • Restaurant Management Service → Notification Service: (Async, Kafka event ORDER_ACCEPTED/REJECTED) to send push notifications.

✅ Why asynchronous?

  • Restaurant may take time (few seconds) to accept.
  • System should not block the user; instead show "Waiting for confirmation".

🚴 Step 5: Assign Delivery Partner

🔥 Services involved:

  • Delivery Assignment Service
  • Delivery Partner Service

📩 Communication:

  • Restaurant Service → Delivery Assignment Service: (Async, Kafka event ORDER_READY) to request pickup.
  • Delivery Assignment Service → Delivery Partner Service: (Async, Kafka event ASSIGN_RIDER) to allocate a delivery person.

✅ Why asynchronous?

  • Finding the nearest available rider can take a few seconds.
  • Needs retries if rider not available.

📍 Step 6: Live Tracking of Order

🔥 Services involved:

  • Tracking Service
  • User Notification Service

📞 Communication:

  • User App → Tracking Service: (Sync, REST API or WebSocket) to get live order location.
  • Delivery Partner App → Tracking Service: (Async, updates every few seconds) to send GPS location.

✅ Why mixed?

  • Delivery boy's app sends async updates in the background.
  • User app polls or uses WebSocket for real-time experience.

🍴 Step 7: Order Delivered and Feedback

🔥 Services involved:

  • Order Service
  • Rating and Review Service

📩 Communication:

  • Delivery Partner App → Order Service: (Async, Kafka event ORDER_DELIVERED) to mark order delivered.
  • User App → Rating Service: (Sync, REST API) to submit rating/review.

✅ Why mixed?

  • Delivery marking can be async.
  • User rating needs quick feedback after submitting.

🧩 Full Service Map (with communication type)

Service Talks to Communication Why
User App → Search Service Sync (REST) Instant restaurant search
User App → Menu Service Sync (REST) Instant menu loading
User App → Cart Service Sync (REST) Real-time cart update
User App → Coupon/Payment Service Sync (REST) Real-time payment validation
Order Service → Restaurant Service Async (Kafka) Restaurant confirmation
Restaurant Service → Delivery Assignment Async (Kafka) Schedule delivery
Delivery Partner App → Tracking Service Async Background GPS updates
User App → Tracking Service Sync (REST/WebSocket) Live order tracking
Delivery Partner App → Order Service Async (Kafka) Mark order delivered
User App → Rating Service Sync (REST) Instant rating feedback

🎯 Why Sync vs Async in Food Delivery?

Synchronous (REST/WebSocket) Asynchronous (Kafka/Event Bus)
Searching restaurants Order confirmation from restaurant
Adding to cart Assigning delivery partner
Making payment Updating live delivery status
Submitting rating Marking delivery completed

🔥 Key Observations:

  • User-facing actions = mostly synchronous.
  • Internal system-to-system actions = mostly asynchronous.
  • Kafka, RabbitMQ, or Pub/Sub used for decoupled communication.
  • REST APIs or WebSockets used for real-time interactions.
  • Scalability, resiliency, and user experience are balanced by picking right communication strategy.

📚 Real-World Example:

  • Swiggy uses gRPC between internal services, Kafka for events, and REST/WebSockets for user interactions.
  • Zomato heavily uses Kafka for order and delivery workflows.

✍️ Final Thought

Building a food delivery platform is not just about delivering food.

It's about designing a resilient, fast, and fault-tolerant system using the right combination of synchronous and asynchronous communication patterns! 🚀🍔