Why You're Probably Thinking About Real-Time Systems The Wrong Way

Companies in many industries are increasingly interested in and attempting to create real-time systems that far exceed the limited capabilities of software systems of the recent past. The problems these systems need to solve impact internal operations and customer experience, and also extend beyond the walls of the individual organization to alter expected industry capabilities, and even the health of the planet.

The next generation of real-time systems comes into play in extremely diverse uses: Safety and Security: Delivering new levels of public health and safety in smart buildings that automatically detect and stop the spread of disease, Retail: Enable new personalized proximity marketing experiences in physical retail environments, Emergencies: detection of floods and other emergencies, then automatic triggering of evacuation protocols

In all of these scenarios, there can be no compromise in terms of responsiveness, reliability, and scalability. This requires development managers to adopt a more modern way of thinking about how these high-performance real-time systems should be architected.

When the database, the primary means of creating real-time systems, fails - How many elevators can you actually monitor - before it fails?

A modern supercity may have buildings with hundreds of thousands of elevators, all of which require constant monitoring to detect situations of interest such as security issues. The best way to address this type of "intelligent building" challenge is to use real-time stream processing that can handle large-scale data analysis and provide consistent and timely situational awareness.

>

Development would probably start with information from a single elevator with analysis done in a simple time series database and small batch queries. But it would be incorrect to assume that what works for one should work for hundreds and then thousands.

The flaw in this assumption is that database queries will be able to handle the data explosion without a massive loss in performance speed. This approach works as expected with a small number of elevators, but the whole system fails when the amount of data (elevators) exceeds the capabilities of the database

Apart from placing other real-time capabilities around the periphery of the traditional database in this system, the use of a database itself is what inherently breaks the system at scale.

The solution to creating a robust scalable system is to perform the anomaly detection analysis in memory and then move the information to the database for historical purposes. The database is the last step, not the first, in a modern real-time system.

The three types of real-time systems

While there is growing interest in real-time systems, with it comes noise, confusion, and misinformation about the different types and capabilities of real-time systems, as well as the suitability (or no) databases versus their ability to scale and run as needed. There are three types of real-time systems, each relevant to solving a different class of problems.

“Hard” real-time systems – hardware-based, Micro-Batch real-time systems – “soft” real-time systems that use more traditional data processes and queries, Event-driven real-time systems – "soft" real-time systems that use stream or event processing. 1. "Difficult" real-time systems

These types of systems are needed to solve problems that cannot tolerate any missing "delays", with performance speed measured in milliseconds. No database could ever offer this kind of performance, and furthermore, all hardware and IT equipment must be done on site. High-precision automated robotic assembly lines require the rigor of this type of real-time system.

2. Micro-batch real-time systems

This approach to real-time systems is most appropriate for problems that only require real-time processing with latencies on the order of hundreds of milliseconds (or even seconds) and require little stake At scale. E-commerce ordering systems can be a good match for this.

Traditional approaches to data processing are applied to small amounts of data (micro-batches) at a rapid "duty cycle". Ground zero for creating fatal issues is in attempts to scale the system and decrease the latency between batches to make these systems...