Real-time at the edge

A logistics platform operating across three continents needed real-time status updates delivered to drivers and dispatch teams on mobile devices. Their existing implementation used polling — every client checked for updates every 30 seconds. At scale, this was generating millions of unnecessary database reads per day and still delivering updates with 30-second latency.

The problem

Real-time mobile notifications touch three separate delivery systems: WebSocket connections for foreground apps, FCM for Android background notifications, and APNs for iOS background notifications. Each has different reliability characteristics, different delivery guarantees, and different failure modes.

The logistics use case added further constraints: notifications needed to carry structured data, not just text, so the mobile apps could update local state without making additional API calls. Delivery failures needed to be tracked and retried. And the system needed to work in regions with unreliable mobile connectivity — where a device might disconnect and reconnect frequently.

What we built

A Go service handled WebSocket connection management and fan-out. Each connection registered its device ID, user ID, and client capabilities. When an event occurred — status change, assignment, alert — the service looked up affected users, found their active connections, and delivered the payload directly. For devices not currently connected, it enqueued a push notification via FCM or APNs as appropriate.

Redis handled two functions: active connection tracking (which devices are connected and to which server instances), and the outbound push queue. The queue implementation included retry logic with exponential backoff and dead-letter handling for consistently undeliverable notifications.

The React Native client was built to handle reconnection gracefully: when the WebSocket connection dropped, it would show a “reconnecting” state, buffer any user actions, and replay them in sequence after reconnection. This mattered in low-connectivity environments where 60-second disconnections were normal.

PostgreSQL stored the notification history and delivery status — important for audit purposes in a logistics context and for showing users what they might have missed during an offline period.

Outcomes

Polling was eliminated entirely. Server-to-device latency for status updates dropped from up to 30 seconds to under 500ms for connected devices. Database read load dropped by approximately 40% once polling was removed.

The WebSocket service handled 12,000 concurrent connections per instance at launch, with horizontal scaling configured to add capacity automatically. The push notification delivery tracking identified a class of Android devices that were consistently failing to receive FCM notifications — a Firebase configuration issue that had been invisible with the polling approach.