The word "real-time" has really become overloaded recently. Here are what it means in the three different problem domains: Web App, Operating System, and Database.
A real-time web application is a web application utilizing the standard WebSocket API to provide live update functions. For example, a stock market dashboard with live updating price data, or a chatroom with live updating messages.
A usual, not real-time, web application is based on the standard HTTP protocol. A server serving the HTTP protocol is passive: to get data from the server, the client must send a request to ask for it. Before WebSocket, developers emulated the live update with polling: asking for the data every second (or you pick the interval).
A HTTP request-response cycle is expensive. Developers cannot ask for data every millisecond. Therefore, there is a delay from when the data is available on the server and when the client asks for, receives, and displays that data.
WebSocket API provides a protocol for the server to push data to the client without the client asking. Instead, the client keeps listening to the server for any data message. The server pushes the data as soon as it is available.
In this context, a real-time database is a database capable of synchronizing data between the client and server continuously via WebSocket. This is different from the real-time databases discussed below.
A database is capable of real-time processing when it processes data as data comes in during service operations. This is as opposed to batch processing, which processes accumulated data while service operations are suspended or relegated to another database.
Real-time processing and batching processing are the result of conflicting needs and priorities. Supporting service operations, real-time processing needs to be responsive, optimized for lower latency. Supporting analysis and decision making, batch processing needs to process more data, optimized for throughput.
A real-time operating system (RTOS) is an operating system which guarantees that its operations can meet a specification of time constraints. Many life-saving applications in the real world have strict time constraints. For example, the airbag on a car must be activated within a very short time after the sensor detects a crash. An implanted heart defibrillator must send out the defibrillation electric shock within a short time after the sensor detects an arrhythmia, as well as stop the electric shock in time. An implanted pacemaker must maintain a steady pace of electric shocks to the heart. The operating systems used in these situations must guarantee that their operations meet the specified time constraints. Slowdowns as experienced in consumer devices are utterly dangerous in these situations.
To make such guarantees, an RTOS is supported by real-time hardware, of which operations are specified to take a consistent time. On top of that, an RTOS schedules the various tasks it performs consistently and predictably. This is as opposed to non-real-time OSes, which may prioritize responsiveness or fairness over consistency.
In this context, a real-time database is a database in which transactions can be specified to meet time constraints, in addition to consistency constraints. It is usually operated on top of a real-time operating system. For example, a financial market usually requires its transactions to finalize within a time constraint.
- FeathersJS real-time web app framework, https://docs.feathersjs.com/
- Firebase Realtime Databse, https://firebase.google.com/products/realtime-database
- Implementation of a real-time database system, https://www.sciencedirect.com/science/article/pii/S030643799600004X
- What is RTOS, https://www.freertos.org/about-RTOS.html
- The polling delay is on average half of the polling interval, assuming a uniform distribution between the worst case and the best case. The best case is 0, when the data is available right before being asked. The worst case is the polling interval, when the data is available right after being asked.