Real-Time App Development | WebSocket & SSE

Persistent bidirectional connections for chat, multiplayer, collaborative tools, and live data feeds -- where polling would require hundreds of requests per minute to achieve the same update latency, and Server-Sent Events would be insufficient because the client needs to send data back to the server. WebSocket server implemented with Socket.io for Node.js applications (which handles protocol fallback, reconnection, and namespaced event routing) or raw ws for minimal-overhead scenarios; Go with gorilla/websocket for applications requiring 100,000+ concurrent connections on a single node. Authentication on WebSocket connections uses JWT token validation during the HTTP upgrade handshake -- not after the connection is established, preventing authenticated message handling before credentials are verified. Redis Pub/Sub (or Redis Streams for ordered, consumer-group message delivery) provides the fan-out layer for multi-node deployments: any connected client on any server node receives events published by any other node. Heartbeat and ping/pong mechanisms detect stale connections that have silently disconnected; client-side reconnection with exponential backoff (100ms, 200ms, 400ms, capped at 30s) restores connections after network interruptions without user-visible failures. Load-tested to your concurrent connection target using k6 or locust before delivery -- connection counts verified, not estimated.

Multi-user editing where multiple people modify the same document, canvas, spreadsheet, or code file simultaneously without overwriting each other's changes -- the engineering challenge that makes Google Docs and Figma fundamentally different from "share a file and take turns." CRDT-based conflict resolution using Yjs (the industry standard for production collaborative editing) handles concurrent text edits, list reorders, and tree structure modifications with mathematically guaranteed convergence -- any two nodes applying the same set of operations in any order will reach the same final state. Yjs document state syncs over WebSocket (y-websocket) or WebRTC peer-to-peer (y-webrtc) depending on your latency and server cost requirements; persistence to PostgreSQL or Redis preserves document state across sessions. For simpler, bounded editing scenarios (short-form fields, chat, simple annotations), Operational Transformation provides a lighter-weight alternative without Yjs's document model overhead. Presence indicators show each connected user's cursor position, selection range, and display name with colour-coded highlighting; awareness state updates over the WebSocket connection in under 50ms. Undo/redo history maintained per-user (not a shared undo stack) so User A's ctrl-Z undoes their own changes without reverting User B's contributions.

Operational dashboards that update automatically the moment underlying data changes -- fleet tracking maps, production line monitoring, financial position displays, IoT sensor readings, and operations centre views -- replacing the manual refresh workflow where operators are always looking at stale data and making decisions on the lag. Backend data pipeline captures changes at the source (database triggers, CDC via Debezium, IoT event streams via MQTT or Kafka) and publishes update events; Server-Sent Events (SSE) delivers one-directional server-to-client updates for read-only monitoring dashboards at lower infrastructure cost than WebSocket; WebSocket handles dashboards where operators interact (acknowledge alerts, update statuses, toggle displays). Frontend built with React and Recharts (for time-series charts), Mapbox GL JS (for geospatial fleet tracking), or Apache ECharts (for complex operational visualisations) with incremental state updates that change only the modified chart data point rather than re-rendering the full chart on each update -- avoiding the visible flicker that makes rapidly-updating dashboards unusable. Designed for thousands of concurrent viewers: SSE fan-out via Redis Pub/Sub, CDN edge delivery for static assets, and chart update batching (100ms debounce) that prevents DOM thrashing when events arrive faster than the browser can render.

Kafka and RabbitMQ message broker design for systems where services need to communicate reliably without tight coupling -- so an order placed in the commerce service triggers fulfilment, inventory decrement, customer notification, and analytics ingestion independently, without the commerce service knowing or caring about those consumers. Apache Kafka for high-throughput, ordered, persistent event streaming where replay capability matters (you can reprocess all events from T-7 days when a downstream consumer had a bug); RabbitMQ for lower-latency task queues and work distribution where ordering and replay are less critical than flexible routing and consumer isolation. Consumer group topology design assigns each downstream service its own consumer group, enabling independent scaling, independent failure, and independent replay without affecting other consumers of the same topic. Dead letter queues capture messages that fail processing after the configured retry limit, with the original message, failure reason, and attempt count preserved for investigation and manual reprocessing. Event schema management using Confluent Schema Registry enforces Avro or Protobuf schema compatibility across producers and consumers -- a schema change that would break a consumer fails the producer at publish time rather than at consumer processing time. Event sourcing and CQRS for backends where the full history of state transitions matters (audit log, temporal queries, event replay for business intelligence).

Push notification systems that reach users within seconds of a threshold crossing, status change, or action requiring their attention -- with delivery confirmation and retry so you know the alert reached its recipient rather than silently failing. WebSocket-delivered in-app alerts include read receipts that mark an alert as seen the moment the user's browser receives it; notifications sent while the user is offline queue and deliver immediately on reconnection. Browser push notifications via the Web Push API (using VAPID keys and the Push API) reach users who aren't actively on the page, with notification content and action buttons configurable per alert type. Webhook fan-out delivers the same event to Slack (incoming webhook or Block Kit messages), PagerDuty (Events API v2 for on-call alerting), Microsoft Teams, or your internal tooling -- each channel with independent retry logic and delivery confirmation. Alert deduplication suppresses repeat notifications for the same underlying condition within a configurable suppression window, preventing alert fatigue when a threshold is repeatedly crossed and cleared. Escalation paths trigger when an alert remains unacknowledged beyond a defined window: first escalation to a secondary contact, second escalation to the on-call manager, with the full escalation chain logged for post-incident review. Per-user notification preferences let each team member control which alert types they receive via which channel without requiring engineering changes.

WebSocket and SSE integrations for React Native and native iOS/Android applications -- with the mobile-specific engineering that makes real-time features reliable on cellular networks and battery-constrained devices, not just on desktop WiFi. Live location tracking uses Core Location on iOS and FusedLocationProvider on Android with configurable accuracy vs. battery trade-offs: high-accuracy GPS for field service dispatch (100% accuracy, significant battery cost) vs. network-based coarse location for asset tracking (lower accuracy, minimal battery impact). Background-to-foreground transitions require explicit WebSocket reconnection on mobile because OS-level background process management suspends network connections differently on iOS (immediate suspension after ~30 seconds) vs. Android (variable, depends on battery optimisation settings); we handle both with reconnection logic that fetches missed events on foreground resume. In-app messaging queues messages sent while the user was offline (stored locally in SQLite or MMKV) and flushes the queue on reconnection with ordering preserved. Firebase Cloud Messaging (FCM for Android, APNs for iOS) handles push notifications that wake the app from terminated state -- the notification payload includes enough data for the app to update its local state without a subsequent network request. Background sync for data that must be current when the user opens the app (unread message counts, inventory levels, shift assignments) uses background fetch tasks scheduled based on usage patterns rather than fixed intervals.