Soft v Hard Real-time Systems

November 04, 2022

Blog

Speed is a selling point in everything, from cars to meal delivery to data management. The term real-time has been used by most in the database system industry to mean fast. For example, real-time processing enables more-or-less immediate results, versus the previous century’s typical overnight batch processing. However, a difference must be noted between real-time processing and real-time systems.

In the latter, real-time means “various operations … that must guarantee response times within a specified time (deadline)” (Wikipedia). A fast database is suitable for real-time processing, but a real-time database that is cognizant of deadlines is required for real-time systems.

It should also be noted that there is a very important distinction between soft and hard real-time systems, and the need for speed.

A soft real-time system is one that wants speed and reliability, and for all tasks to complete within a window of time scheduled by the developer. Faster is usually better, but a missed deadline is not a life-or-death matter. One such example is voice over IP, or VoIP.  If a task runs past its deadline, it might result in poor call quality or maybe even a dropped call. It might feel extremely important and frustrating to the telemarketer on the phone, but the entire system doesn’t fail, and no lives are lost. 

The complete system failure of a soft real-time system is averted because a soft real-time system has the luxury of tolerating missed deadlines. 

A hard real-time database system must enforce set transactions deadlines without fail.  Speed might be desirable, but it is not a necessity. Ultra-fast might feel fun when test-driving a new sportscar, but is it fast enough to apply the brakes and avoid hitting that pedestrian who was texting instead of looking at the crossing light? Most would prefer a braking system with guaranteed deadlines, and therefore guaranteed response time, under such circumstances. 

Hard-real time database system transactions are only allowed if they are able to finish within their set deadline. Transactions that are destined to be late are identified, interrupted, and forced to initiate rollback in time to satisfy deadlines. The real-time database system’s goal is not to ensure speed (that is the purview of the real-time system developer that determines appropriate deadlines), but to maximize the number of transactions that meet their deadline. Speed, without a firm deadline for transaction rollback or commit, can actually kill. Or, to put it another way, under certain circumstances, speed is only a good thing if you have reliable brakes.