EASYwalkthrough
Push Notifications for Offline Users
When User B is offline, the message must still reach them. We cannot hold the message indefinitely on the chat server because the server may restart, losing in-memory state.
If B is offline (key expired or status = offline), the service writes the message to Cassandra (durable storage) and enqueues a push notification to a notification service. The notification service sends the alert via APNs (Apple Push Notification service) for iOS or FCM (Firebase Cloud Messaging) for Android.
“The delivery flow: the chat service checks B's presence in Redis.”
Why not send the push immediately from the chat service? Because push delivery has its own retry logic, rate limiting (APNs throttles at ~1,000 notifications/sec per connection), and device token management.
Separating it into a dedicated service isolates these concerns. When B comes back online and establishes a WebSocket connection, the client sends its last_seen_sequence_number per conversation.
The server queries Cassandra for all messages with sequence numbers greater than last_seen and delivers them in order. This is the catch-up sync mechanism.
We use Cassandra's clustering key (message_id DESC) to efficiently fetch missed messages: it is a single sequential read per conversation. For users with many conversations, we batch the catch-up queries and stream results over the WebSocket as they arrive.
Trade-off: push notifications have 1-5 seconds of latency (APNs/FCM processing time), so offline delivery is slower than online WebSocket delivery (~200ms). We accept this because the alternative (holding messages in memory until reconnection) risks data loss on server crash.
Related concepts