Why Real-time Matters in Mobile
Users expect instant feedback. When someone sends a message, the recipient should see it within milliseconds. When a stock price changes, the chart should update live. Traditional HTTP request-response is inherently pull-based: the client asks, the server answers. Real-time communication flips this to push-based: the server notifies the client when something changes.
Real-time Technologies
WebSockets
WebSocket is a full-duplex communication protocol that maintains a persistent connection between client and server. It is bidirectional, low latency, and supports both binary and text data. Connections start as an HTTP request that gets upgraded to the WebSocket protocol with minimal per-frame overhead (2-14 bytes).
Server-Sent Events (SSE)
SSE is a simpler alternative for server-to-client streaming. It is unidirectional (server pushes to client only), HTTP-based (works through proxies without special configuration), and includes auto-reconnect with last-event-id tracking. Ideal for live feeds, notifications, and progress updates.
Long Polling
Long polling is a fallback where the client makes an HTTP request that the server holds open until new data is available. Universal compatibility but higher latency and overhead than WebSocket or SSE.
Mobile-Specific Challenges
Connection Lifecycle
Mobile connections are inherently unstable. Your implementation must handle network transitions (WiFi to cellular), app backgrounding (iOS suspends connections within ~30 seconds), and NAT timeouts (carriers may drop idle connections after 30-60 seconds).
Battery Optimization
- Send ping/pong frames every 25-30 seconds (not more frequently)
- Disconnect when backgrounded, reconnect when foregrounded
- Use push notifications for backgrounded delivery instead of maintaining connections
- Batch updates to combine multiple small messages
Reconnection Strategy
Implement exponential backoff with jitter: 1s, 2s, 4s, 8s up to 30s maximum with random jitter to prevent thundering herd. Always send a last-received timestamp so the server can replay missed messages.
Managed Real-time Services
Ably
Enterprise-grade real-time messaging with 99.999% uptime SLA, message persistence, presence tracking, and 25+ client SDKs. Free tier: 6M messages/month.
Pusher
Developer-friendly with channels-based pub/sub model, presence channels, and client events. Free tier: 200K messages/day, 100 concurrent connections.
Socket.IO
Open-source library with automatic transport fallback (WebSocket to long polling), room-based broadcasting, and binary streaming. Requires self-hosted Node.js server.
Firebase Realtime Database
JSON tree structure with real-time sync, offline persistence, and automatic conflict resolution. Included in Firebase free tier.
Architecture Patterns
Pub/Sub (Publish/Subscribe)
Clients subscribe to channels. When data changes, the server publishes to relevant channels. All subscribed clients receive the update. The most common pattern for chat, feeds, and notifications.
Optimistic Updates
Apply changes locally before server confirmation. If the server confirms, do nothing. If rejected, roll back and show an error. Makes the UI feel instant.
Scaling Considerations
| Challenge | Solution |
|---|---|
| Many concurrent connections | Use managed services or sticky session load balancer |
| Message fan-out | Redis Pub/Sub or NATS as message broker |
| Global latency | Multi-region servers with connecting message bus |
| Connection state | Store in Redis, not in-memory |
When to Use What
- Chat and messaging - WebSocket (bidirectional, low latency)
- Live feeds and notifications - SSE (simple, unidirectional)
- Collaborative editing - WebSocket with CRDTs or OT
- Score updates and tickers - SSE or managed pub/sub