“Can We Make It Update in Real Time?”
A client was walking through their dashboard.
It showed order counts, revenue, and inventory levels. Solid stuff. Clean layout. The numbers updated whenever the page was refreshed.
Then came the question.
“Can we make it update in real time?”
A few clarifying questions followed.
“How often does this data actually change?”
“Throughout the day. Maybe… 20–30 orders per day?”
“So roughly one order per hour during business hours?”
“Yeah, that sounds about right.”
“And how often do people look at this dashboard?”
“The owner checks it a few times a day. Staff looks at it when they need to.”
A pause.
“So what you’re asking for is WebSockets, server-sent events, and live data syncing… for information that changes once an hour and is glanced at a handful of times a day.”
The client thought about it for a second.
“…Okay, maybe we don’t need real-time.”
Exactly.
The Real-Time Hype Problem
Real-time features feel impressive.
Numbers ticking up without refreshing the page. Dashboards that look alive. It screams modern, enterprise, we know what we’re doing.
And sometimes? Real-time is absolutely the right call:
- Chat apps (messages should appear instantly)
- Collaborative editing (seeing others type in real time)
- Trading platforms and monitoring systems
- Multiplayer games
- Live sports scores
But most business applications?
They don’t need instant updates.
They need timely enough updates.
Those are very different things.
What “Real-Time” Actually Costs
Real-time sounds like a UI feature.
In reality, it’s an architectural decision—with consequences.
Development Complexity
WebSockets mean:
- Persistent server connections
- Connection lifecycle management (disconnects, reconnects, retries)
- Message queues
- State synchronization
- Harder testing scenarios
Polling, on the other hand, is:
- A normal API endpoint
- A scheduled request from the client
- Plain old HTTP
Boring? Yes.
Reliable? Also yes.
Infrastructure Cost
WebSocket connections stay open.
- 100 users = 100 permanent connections
- 1,000 users = 1,000 connections
- 10,000 users = 🔥
Traditional HTTP closes the connection after each request. Much lighter. Much cheaper.
Debugging (a.k.a. Emotional Damage)
When polling breaks:
“API request failed.”
Clear. Obvious. Fixable.
When WebSockets break:
- Connection dropped, client didn’t notice
- Messages sent but never received
- Reconnect loops
- Client and server disagree about reality
Debugging WebSockets in production is… an experience. And not the fun kind.
Scaling Is Harder Than It Looks
Scaling HTTP APIs is well-understood:
- Add servers
- Use a load balancer
- Move on with your life
Scaling WebSockets?
- Sticky sessions
- Shared state (Redis, message brokers)
- Connection coordination across servers
Doable—but not trivial.
When Polling Is More Than Enough
For that dashboard?
Polling every 30 seconds was the solution.
setInterval(fetchStats, 30000); // Update every 30 seconds
That’s it.
Benefits:
- Simple to implement
- Easy to debug
- Works everywhere
- Scales cleanly
- No persistent connections
Downsides:
- Updates aren’t instant
For data that changes once an hour and is checked a few times a day, a 30-second delay is effectively invisible.
The Middle Ground Options
Sometimes 30 seconds feels a little slow—but WebSockets still feel like overkill.
There are options.
Server-Sent Events (SSE)
- Server pushes updates over HTTP
- One-directional (server → client)
- Simpler than WebSockets
Good for:
- Notifications
- Activity feeds
- Progress updates
Faster Polling
Poll every 10 or 5 seconds.
Good for:
- Inventory dashboards
- Order tracking
- Status pages
Still simple. Still boring. Still effective.
Long Polling
Client waits. Server responds only when data changes.
Feels real-time. Uses HTTP. Less infrastructure pain.
The Questions That Actually Matter
When someone asks for “real-time,” good consultants don’t say yes or no.
They ask questions.
How often does the data change?
- Seconds? Real-time.
- Minutes? Maybe.
- Hours? Probably not.
How time-sensitive is it?
- Stock prices? Yes.
- Order totals? No.
- Daily summaries? Definitely no.
How many users will be connected at once?
- 10 WebSocket users? Fine.
- 10,000? Expensive.
What do users expect?
- Chat apps expect instant.
- Dashboards expect “updated.”
What’s the infrastructure budget?
- Basic hosting? WebSockets may not even be viable.
- Full cloud setup? More options.
A Gym Dashboard Reality Check
A gym wanted a live dashboard showing who was currently checked in.
On paper? Perfect WebSocket use case.
In reality:
- People checked in during two short time windows
- The dashboard was on a back-office TV
- Nobody stared at it continuously
Solution: polling every 15 seconds.
Result?
- Names appeared quickly
- The dashboard felt live
- No added complexity
To users, 15 seconds felt the same as instant.
When Real-Time Is Worth It
Real-time absolutely has its place.
- Instant notifications for new orders
- Collaborative editing and comments
- Live delivery tracking
In those cases, the complexity buys real user value.
That’s the key: value.
A Pragmatic Decision Framework
A solid default approach:
- Start with polling (30 seconds)
- If users complain → reduce to 10–15 seconds
- Still not enough? → consider SSE or long polling
- Need instant, bi-directional communication? → now WebSockets make sense
Most projects never leave step one.
The Bottom Line
Real-time features are powerful—but they’re often unnecessary.
Before building them, ask:
“Does the business truly need instant updates, or would ‘updated within 30 seconds’ solve the problem just as well?”
Most of the time, the answer is polling.
And simple + boring + reliable beats complex + impressive + fragile—especially when users can’t tell the difference anyway.
Takeaway:
Real-time is a tool, not a badge of honor. Use it when the business actually needs it—not just because it sounds cool. Your infrastructure, your budget, and whoever has to debug this six months from now will thank you.