"Real-time" is one of the most overloaded terms in software. The gap between what it means in a marketing context and what it means in a technical context causes real problems for businesses that depend on live data to make decisions.
"Real-time" often means "faster than the thing you had before", which isn't the same as actually live. When a vendor says their dashboard is "real-time," they might mean the data refreshes every 30 seconds. Or every minute. Or that it updates live, but only after a human uploads a file.
Real-time is event driven, not just frequent refreshes.
A genuinely real-time system is one where data changes on the client are driven by events on the server, not by the client periodically asking "has anything changed?" The technical implementation is usually WebSockets or Server-Sent Events: a persistent connection where the server pushes updates as they happen, rather than waiting to be asked.
Polling, where the client asks the server for new data every N seconds, is not real-time. It's close to real-time, depending on the polling interval, but there's always a delay between when something happens and when the dashboard shows it. For commodity trading, or live dispatch management, or any system where decisions need to be made on current information, that gap matters.
The problem is that polling looks like real-time to most users, right up until it doesn't. When the polling interval is 30 seconds and you make a decision based on data that's 28 seconds old, the consequences aren't always obvious until something goes wrong.
Polling is easier. Real-time takes more engineering.
Building a genuinely real-time system is harder than building one that polls. WebSocket connections need to be managed. They disconnect, they need to handle reconnection, they need to maintain state across connection drops. The backend needs a pub/sub architecture to broadcast updates to multiple clients efficiently. Under load, the connection management becomes a significant engineering concern.
Polling is simpler. It works. For a lot of use cases, it's good enough. The problem is when businesses are sold on "real-time" dashboards that are actually polling every minute, and only discover the gap when they're making decisions that depend on the data being current.
The architecture should match the cost of stale data.
The honest answer is that real-time isn't always necessary. For most reporting use cases, weekly sales figures, monthly P&L, end-of-day operations summaries, a dashboard that refreshes every few minutes is perfectly adequate. The data doesn't need to be live because the decisions aren't live.
But for commodity pricing, live dispatch visibility, active trading, or any system where a decision made on stale data has a real cost, genuine real-time matters. The question to ask isn't "is this dashboard fast?" It's "what's the cost of making a decision on data that's 30 seconds old?"
If the answer is "nothing significant," polling is fine. If the answer is "we could lose a trade, miss a dispatch, or make a wrong call", then the architecture needs to be built for the actual requirement, not the easier implementation.
SSS builds data platforms and dashboards for South African businesses, including genuinely real-time systems where the use case demands it. We scope the data requirements before we design the architecture.
Talk about your data problem →