Realtime Sockets - mukular/food-delivery-feastfast--architecture GitHub Wiki

Real-Time Communication (Sockets)

This document explains how real-time features are implemented using Socket.IO, including order updates, delivery tracking, and role-based communication.

1. Why Real-Time Is Needed

The platform involves multiple actors interacting simultaneously:

  • Customers waiting for order updates
  • Restaurants updating order status
  • Delivery partners sharing live location

Polling would:

  • Increase server load
  • Waste bandwidth
  • Add latency

Socket.IO enables low-latency, event-driven communication.

2. Technologies Used

  • Socket.IO (WebSocket + fallback)
  • Redis (session-based auth support)
  • Rooms-based event routing

3. Socket Architecture Overview

Client (Browser / Mobile)
      ↕ WebSocket
Socket Server (Node.js)
      ↕
Business Logic + DB

Sockets run alongside Express, not inside controllers.

4. Authentication Strategy

Sockets use session-based authentication, not JWT.

Flow

  1. User logs in via HTTP
  2. Session stored in Redis
  3. Socket handshake includes cookies
  4. Server validates session
  5. Socket connection accepted

Benefits

  • Same auth rules for HTTP & sockets
  • Device-level session control
  • Secure role-based access

5. Room Design (Critical)

Rooms are the backbone of scalability.

5.1 Customer Room

Note: Role-prefixed rooms are used for clarity. Internally, this can also be abstracted as a generic user:{userId} room.

customer:{userId}

Used for:

  • Live Delivery Boy Tracking
  • Order updates

6. Events by Role

6.1 Customer Events

Order status updated

Event:

order:status_changed

Payload:

{
  "orderId": "abc123",
  "shopName": "Awadhi Kitchen",
  "previousStatus": "ready",
  "newStatus": "out_for_delivery"
}

Handled by:

  • Toast notification
  • Optional query invalidation

Live location update

Event:

delivery:location_update

Emitted every few seconds while delivering.

7. Live Delivery Tracking

Flow

  1. Delivery app emits location
  2. Socket server broadcasts
  3. Customer receives updates
  4. Map re-renders marker

Optimization

  • Throttled updates
  • Distance-based emit control
  • Battery-friendly

8. Client-Side Handling

Centralized Socket Hooks

  • useCustomerSocket
  • useCustomerOrderSocket

Benefits:

  • Clean layout components
  • Reusable logic
  • Controlled side-effects

Toast-Based UX (Customer)

Instead of heavy UI updates:

  • Toast notifications for most events

9. Event Emission Rules

Scenario Emit Event
Order confirmed ✅
Order prepared ✅
Out for delivery ✅
Delivered ✅
Wallet payment ❌
Menu update ❌

Only user-facing lifecycle changes are emitted.

10. Reliability & Idempotency

  • Events are stateless
  • API remains source of truth
  • Socket events enhance UX only

If an event is missed:

  • HTTP fetch resolves correct state

11. Scaling Strategy

Horizontal scaling ready.

Socket Server 1
Socket Server 2
Socket Server 3
        ↕
      Redis

Supports:

  • Redis adapter
  • Multi-instance broadcasting

12. Error Handling

  • Invalid session → socket disconnected
  • Unauthorized room join → rejected
  • Network failure → auto reconnect

13. Security Considerations

  • No sensitive data in events
  • Auth verified before room join
  • Role-based room access
  • Server-side validation enforced

14. Why This Design Is Production-Grade

  • Scalable
  • Secure
  • Battery-efficient
  • Low latency
  • Clean separation of concerns
  • Easy to debug