HUB · 8 GUIDES
Real-time systems
Event-driven architecture, message queuing and API design that keep live data accurate across Australian time zones.
Quick answer: Real-time systems keep operational data accurate within seconds by using event-driven architecture, UTC-normalised timestamps and staged legacy modernisation instead of nightly batch processing.
Last updated
Quick answer
What is a real-time system, and does a growing business actually need one?
A real-time system delivers and processes data within seconds of it occurring rather than on a batch schedule; it's worth building once stock, dispatch or pricing decisions rely on data older than an hour.
Additional Context
Most Australian mid-sized operators start on nightly batch jobs. Real-time architecture earns its cost once decisions - restocking, order allocation, pricing - are being made on figures that are already stale by the time someone reads them.
Sources
- Australian Government API Design Standard
Sets expectations for consistent, secure API design across Australian government and connected systems.
- Digital Service Standard
DTA criteria for service performance, reliability and user experience that inform real-time platform design.
Architecture patterns
Where real-time systems actually fail
Real-time platforms rarely fail because the code is wrong on day one. They fail because a design decision made for a single time zone breaks quietly once the business operates across several. A retailer with warehouses in Perth and Brisbane pushes a stock update timestamped against a Sydney server; the moment daylight saving shifts the eastern clock and Western Australia stays put, the western warehouse reads the update hours later than intended and a dispatch call gets made on stale numbers. This is the failure mode that shows up as "the dashboard's wrong" in a support ticket, when the actual fault is a missing UTC normalisation step buried months earlier, well after the system passed every test in a single-time-zone staging environment.
The second recurring problem is a system built to poll when it should stream. A service that checks an endpoint every thirty seconds for order status looks fine at ten orders a day and starts dropping updates or timing out at scale. Teams that later adopt server-sent events for one-directional feeds, or restructure the flow around a proper message broker design, generally find the fix is less about raw capacity and more about matching the transport pattern to how the data actually moves.
Event-driven architecture versus polling
Polling is simple to build, which is why most systems start there. It becomes a liability once update frequency needs to drop below a minute, or once several consumers need the same event without hammering the source system. Event-driven architecture, where a change publishes once and interested systems subscribe, trades that simplicity for a real reduction in load and latency, but it introduces its own discipline: every event needs a stable schema, a replay strategy for when a consumer is offline, and a clear owner for what happens when two events arrive out of order. Getting that ordering guarantee wrong under genuine multi-state load is the single most common cause of an "it worked in testing" real-time incident.
Common failure pattern
Real-Time Systems That Break Under Multi-State Load
Problem
Dashboards, stock feeds and order pipelines that work fine in a single office start returning stale or conflicting data once a business runs across more than one Australian time zone or scales past a few hundred concurrent events.
Common Pain Points:
- Stale multi-site dashboards Figures differ from site to site because updates aren't normalised to a single time reference.
- Manual reconciliation Staff cross-check numbers between systems every day because nobody fully trusts the live feed.
- Fragile legacy integrations A single slow upstream endpoint can silently stall the entire real-time pipeline.
Business Impact:
Time Wasted: Hours per week reconciling mismatched stock or order figures across sites
Cost Implication: Recurring manual double-checking that grows heavier with every new site added
Opportunity Cost: Decisions made on data that's already wrong by the time someone reads it, from restocking to pricing
Solution
Staged migration to event-driven architecture with UTC-normalised timestamps, proper message queuing and API contracts that let legacy and new systems run side by side during the transition.
Our Approach:
- Audit current data flow(1-2 weeks)
Map every place data currently gets timestamped, polled or batched, and identify where daylight saving or state-based time zones are already causing drift.
- Introduce an event backbone(4-8 weeks)
Add a message queue or event bus alongside the existing system rather than replacing it outright, so real-time and batch processes can coexist during transition.
- Migrate consumers incrementally(Ongoing, phase by phase)
Move dashboards, alerts and downstream systems onto the event feed one at a time, validating against legacy output before each switchover.
Expected Outcome: Operational data reflects reality within seconds, not hours, with time zone handling built into the architecture from the start.
Key Takeaways
What actually keeps real-time platforms reliable
- Normalise every timestamp to UTC before it enters the pipelineCritical
Storing and transmitting events in UTC, then converting only at the display layer, removes the entire class of bugs caused by AEST, AEDT, ACST and AWST offsets colliding.
- Match the transport pattern to how data actually movesImportant
One-directional feeds suit server-sent events, bidirectional needs suit WebSockets, and decoupled multi-consumer flows suit a message queue. Picking the wrong one is the most common early design mistake.
- Migrate consumers one at a time, never the whole system at onceImportant
Running the legacy batch process and the new event feed in parallel during transition lets you validate output before anyone depends on the new pipeline for a live decision.
- Design for replay from day one, not after the first outageImportant
A consumer that's offline for ten minutes needs a way to catch up without missing or duplicating events; retrofitting this after an incident is far more disruptive than building it in upfront.
Reliable real-time platforms come from normalised timestamps, transport patterns matched to actual data flow, staged migration and built-in replay, not from bigger servers.
Real-time infrastructure by the numbers
Figures below relate to the operating conditions that shape real-time platform decisions for Australian businesses running across multiple states and time zones.
3 standard zones, plus DST variance
Time zones affecting Australian operations
Significance: highAustralia runs three standard time zones (AEST, ACST, AWST); daylight saving in NSW, VIC, SA, TAS and the ACT creates a fourth effective offset for around half the year, a common source of real-time sync bugs.
Source: Geoscience Australia, national time zone reference
Documented, versioned APIs
API design expectation
Significance: mediumThe Digital Transformation Agency's API design guidance sets the baseline Australian public-sector and connected systems are expected to meet for versioning, documentation and backward compatibility.
Source: Digital Transformation Agency, API Design Standard
Staged, not big-bang
Legacy modernisation approach
Significance: mediumGovernment and enterprise digital service guidance consistently favours incremental replacement of legacy systems over full rewrites, reducing the risk window during live operation.
Source: Digital Transformation Agency, Digital Service Standard
Methodology
Observations drawn from published Australian Government digital standards and geographic time zone references, applied to the architectural decisions real-time platforms require.
Modernisation approach
Bringing a legacy system into real time without a rewrite
Most legacy platforms weren't built for streaming data; they were built for nightly batch jobs and end-of-day reports, and rebuilding them from scratch to add real-time capability is rarely justified against the risk of a full rewrite. The more reliable route is a strangler fig pattern: wrap the legacy system in an API layer, route new real-time traffic through that layer, and migrate functionality across in stages while the original system keeps handling the production workloads it was already trusted with. Businesses that take this staged path avoid the single biggest risk of a real-time rebuild: an outage during the exact period when both the old and new systems need to be trusted at once.
One pattern worth watching for on a live dashboard rollout is the system that shows correct figures in the demo, on one site, in one time zone, and then returns inconsistent totals the first week it runs across a Perth site and an eastern-states site simultaneously. That gap almost always traces back to a timestamp assumption baked in early and never revisited, which is why the audit step in any real-time project should look specifically for hard-coded time zone offsets, not just performance bottlenecks.
Choosing the right integration pattern
Three questions decide the architecture: does data need to flow one way or two, does more than one system need the same event, and how long can a consumer sit offline before it matters. One-way feeds to a browser suit server-sent events; two-way interactive updates suit WebSockets; anything with multiple consumers, retries or an audit trail belongs on a message queue. A live operational dashboard built for a logistics or manufacturing floor usually needs all three at different layers, which is where real-time systems built for hardware interfaces show the same principles applying well outside a typical office software stack.
Ready to make your real-time data trustworthy?
Share the systems generating your real-time data today - stock feeds, order queues, dashboards - and where gaps between sites or time zones are already showing up.
Real-Time Systems: Common Questions
What's the difference between platform engineering and DevOps for a real-time system?
DevOps is a set of practices for shipping and operating software reliably; platform engineering is the discipline of building the internal tooling and infrastructure that make those practices repeatable across teams. For real-time systems, platform engineering means the event bus, deployment pipeline and monitoring get built once as shared infrastructure, rather than each team wiring up its own message queue and timestamp handling from scratch.
What is API-first development and why does it matter for real-time platforms?
API-first development means designing the interface contract before writing the implementation behind it, so consumers - dashboards, mobile apps, partner systems - can be built against a stable specification while the backend evolves. For real-time systems this matters because a legacy system and a new event-driven service can expose the same API shape during migration, so nothing downstream needs to change twice.
Is cloud engineering the same as cloud computing?
Cloud computing describes the delivery model: compute, storage and services provisioned on demand over the internet. Cloud engineering is the practice of designing, building and operating systems on that model, choosing regions for latency, configuring auto-scaling, and setting up the redundancy a real-time platform needs to keep processing events during a regional outage or traffic spike.
How is application modernisation different from a full system rewrite?
Modernisation replaces or wraps parts of an existing system incrementally, keeping it operational throughout, while a rewrite decommissions the old system and replaces it wholesale. For a live real-time platform, modernisation is almost always the safer path because it avoids the period where the business depends on a new system that hasn't yet proven itself under real production load.
What should a business look for in a system integration partner for real-time work?
Evidence of having connected event-driven infrastructure to the specific systems already in place - accounting platforms, e-commerce systems, warehouse or POS software - rather than a generic integration claim. Ask how they've handled time zone normalisation and failure recovery on a previous build, since those two issues cause most real-time incidents that don't show up in a demo environment.
How long does it typically take to add real-time capability to an existing platform?
It varies with how tightly coupled the existing system is to batch processing, but a staged rollout - audit, event backbone, incremental consumer migration - typically runs across a few months rather than weeks, with the first live dashboard or feed usually deliverable well before the full migration finishes. Treat any fixed-timeline promise with scepticism until the audit is done.