What is real-time updates?
Real-time updates means data on the screen changes as it changes in the system — without the user refreshing the page. A new message appears instantly. An order status flips from "preparing" to "ready" the moment it's updated. A dashboard counter increments as events occur.
This is different from polling, where the client asks the server "anything new?" on a fixed interval (say, every 5 seconds). Polling works but is wasteful — most requests return nothing, and there's always a lag. Real-time connections eliminate the lag and reduce unnecessary server load at scale.
Common use cases include chat, live order tracking, collaborative document editing, live auction bidding, operational dashboards, and delivery status screens.
When does your app need it?
- Users need to see status changes without refreshing — order updates, job status, booking confirmations
- Multiple users are working in the same context simultaneously (collaborative editing, shared boards)
- You're building a live dashboard where staleness matters — stock, bids, support queue depth
- Chat or messaging is part of the product (real-time is required, not optional)
- Users will complain if they miss events — live auctions, ticketing, limited-availability bookings
- Your current polling approach is generating high API load or noticeable lag
How much does it cost?
Adding real-time updates typically adds 8–16 hours of development — roughly $1,000–$4,000 AUD.
Lower end: One-way Server-Sent Events (SSE) for simple status updates or live counters — e.g. order tracking with a handful of status transitions. SSE is simpler to implement and works over standard HTTP.
Higher end: Bi-directional WebSocket connections, multiple event channels, presence indicators (who's online), conflict resolution for collaborative editing, reconnection handling, and a managed pub/sub service wired into your existing data model. Horizontal scaling with WebSockets also requires sticky sessions or a message broker (Redis Pub/Sub), adding infrastructure complexity.
How it's typically built
For one-way updates, Server-Sent Events (SSE) are the simplest path — a persistent HTTP response that streams events as they occur. The browser's native EventSource API handles reconnection automatically.
For bi-directional communication, WebSockets (via the ws library or Socket.io) establish a persistent TCP connection. Socket.io adds useful abstractions: rooms, namespaces, and automatic fallback to polling for environments that don't support WebSockets.
For teams who don't want to manage WebSocket infrastructure, managed services like Ably or Pusher offload the hard parts. They're reliable and easy to integrate, but carry a monthly usage cost that grows with concurrent connections and message volume.
Questions to ask your developer
- Do you need two-way communication or just server-to-client? SSE handles most status-update use cases and is simpler to build and operate.
- How many concurrent connections do you expect? Architecture that works for 100 users may not for 10,000 — ask about the scaling plan.
- Are you using a managed service or building on raw WebSockets? Managed services cost more per month but save build and ops time.
- How is reconnection handled? Clients drop connections — the implementation should handle this gracefully without losing events.
- Does real-time need to work on mobile? Background connections behave differently on iOS and Android.
See also: In-app chat · Public API and webhooks · App cost calculator