Notifications

The platform is designed to alert users within seconds of a critical event (e.g., Horse Cast).

Channels

1. In-App (Bell Icon)

   • Persistence: Saved in database (notifications table).
   • Real-Time: Delivered via Websocket (camera:alert event).
   • Service: NotificationService.

2. Email

   • Provider: SMTP (Configurable via .env).
   • Usage: Weekly reports, Critical Alerts (if configured).

3. SMS

   • Provider: Twilio.
   • Usage: Critical Alerts ONLY (High cost, user must opt-in).

4. Mobile Push

   • Provider: Expo Push API / Google FCM.
   • Service: ExpoServerSdk.

Real-Time Architecture

The system uses a robust Pub/Sub architecture to ensure reliable notification delivery across distributed instances and during restarts.

Components

1. Socket.IO Rooms:

   • Users subscribe to a dedicated "Room" upon connection: socket.join('user_{userId}').
   • This replaces manual socket tracking and eliminates memory leaks.

2. Redis Adapter:

   • Serves as the communication bus between backend instances.
   • When an API node emits a notification, it publishes to Redis.
   • All API nodes receive the message and forward it to their connected clients participating in the target Room.

Event Flow

Resilience & Auto-Healing

The system is designed to handle server restarts transparently:

1. Server Restart: Connections drop, backend memory (Rooms) is cleared.
2. Client Reconnection: Frontend socket.io-client automatically attempts reconnection (backoff strategy).
3. Resubscription: Upon connect event, the frontend immediately re-emits subscribeToNotifications.
4. Recovery: The new socket joins the user_{id} room, and real-time alerts resume instantly.