Real-time systems are everywhere—from the smartphone in your pocket to the aircraft overhead, from the trading floor to the factory floor. Understanding how real-time principles apply across diverse domains builds the intuition necessary to design new real-time systems effectively.

This page examines real-world use cases across multiple industries, exploring their specific requirements, architectural patterns, and the engineering tradeoffs that make them work. Each domain offers unique lessons that transfer to other real-time applications.

Why study use cases?

Theoretical knowledge alone is insufficient for real-time system design. Each domain has discovered, often through painful experience, the specific patterns and anti-patterns that work for their constraints. Studying these use cases provides:

• Pattern recognition — Identifying common real-time challenges across domains
• Architectural templates — Proven designs that can be adapted to new problems
• Requirement intuition — Understanding what latency targets are realistic for different applications
• Failure mode awareness — Learning from others' mistakes before making your own

Online gaming represents one of the most demanding soft real-time domains, combining strict latency requirements with massive scale and the need for fairness across geographically distributed players.

Latency requirements by game genre:

Architectural patterns in gaming:

1. Authoritative Server Model: The server maintains the authoritative game state. Clients send inputs to the server, which validates, applies, and broadcasts results. This prevents cheating but adds network latency to every action.

2. Client-Side Prediction: Clients predict the outcome of their own actions immediately, then reconcile with the authoritative server response. This hides latency for local actions but requires correction when predictions are wrong ("rubberbanding").

3. Lag Compensation: Servers "rewind time" to evaluate actions in the context of what the player saw when they acted. If a player clicked on a target 80ms ago (their view at that time), the server validates the hit against the game state 80ms in the past.

4. Tick Rate and Update Frequency: Game servers typically run at fixed tick rates (e.g., 64Hz for CS2, 128Hz for competitive). Higher tick rates provide more temporal resolution but require more CPU and bandwidth.

5. Network Interpolation: Clients smooth movement between received state updates using interpolation, typically showing the world 50-100ms in the past to always have data to interpolate between.

High-frequency trading (HFT) and electronic market making represent the extreme end of firm real-time requirements, where microseconds translate directly to profit or loss.

The speed imperative:

In liquid markets, the first participant to react to new information captures the profit opportunity. Being 10 microseconds slower than a competitor means consistently losing money. This creates a relentless optimization pressure that pushes systems to fundamental physical and computational limits.

Latency breakdown in trading systems:

Architectural patterns in trading:

1. Co-location: Trading firms pay exchanges for server space in the same data center as the exchange's matching engine, minimizing network latency. The "last mile" from co-lo cage to exchange is carefully measured.

2. Kernel Bypass: Standard network stacks add tens of microseconds of latency. Trading systems use technologies like DPDK (Data Plane Development Kit) or custom network drivers to send packets directly from userspace to the NIC, bypassing the kernel entirely.

3. FPGA Acceleration: Field-Programmable Gate Arrays process market data and generate orders in hardware, achieving sub-microsecond latencies that software cannot match. Common uses include packet parsing, risk checks, and simple strategy execution.

4. Lock-Free Data Structures: Mutex contention adds unpredictable latency. Trading systems use lock-free queues (LMAX Disruptor pattern), atomic operations, and single-writer architectures to eliminate lock contention.

5. Memory Pooling: All memory is pre-allocated. No malloc() calls in the hot path. Object pools and ring buffers provide allocation-free data management with predictable timing.

Industrial control systems represent the classic domain of hard real-time computing, where missing deadlines can cause equipment damage, production loss, or worker injury.

Control loop fundamentals:

Industrial control systems continuously execute a control loop:

1. Sense — Read sensors (temperature, pressure, position, speed)
2. Compute — Calculate control output based on setpoint and current state
3. Actuate — Apply control output (valves, motors, heaters)
4. Repeat — Execute the cycle at a fixed frequency

The cycle frequency depends on the dynamics of the process being controlled:

Industrial control architecture:

1. Programmable Logic Controllers (PLCs): PLCs are specialized hard real-time computers designed for industrial environments. They feature:

• Scan-based execution (read all inputs → execute logic → write all outputs)
• Deterministic timing guaranteed by simple, predictable execution model
• Rugged hardware for factory floor conditions (vibration, temperature, electrical noise)
• Typically programmed in IEC 61131-3 languages (Ladder Logic, Structured Text)

2. Distributed Control Systems (DCS): Large industrial processes use distributed architectures:

• Multiple controllers handling different process areas
• Reliable industrial networks (PROFINET, EtherNet/IP, EtherCAT)
• Hierarchical structure: field devices → controllers → supervisory systems
• Redundancy at every level for high availability

3. Real-Time Industrial Networks: Industrial Ethernet variants provide deterministic networking:

• EtherCAT: Sub-microsecond jitter, high-speed motion control
• PROFINET IRT: Isochronous real-time for factory automation
• Time-Sensitive Networking (TSN): Emerging standard for IT/OT convergence

Real-time communication (RTC) systems—video conferencing, VoIP, live streaming—face the challenge of delivering continuous media over best-effort networks while maintaining human-perceptible quality.

The fundamental constraint:

Unlike file downloads where you can wait for missing data, live media must be played at a fixed rate. If a video frame or audio sample doesn't arrive in time, you either display degraded content or nothing at all. The network and the human auditory/visual system create competing timing constraints.

Latency budgets for real-time communication:

Architectural patterns in RTC:

1. UDP Transport: TCP's reliable, ordered delivery adds latency through retransmission and head-of-line blocking. RTC systems use UDP for media transport, accepting some packet loss in exchange for lower latency. For VoIP, a lost packet is better than a late packet.

2. Jitter Buffers: Network jitter is smoothed by buffers that delay playback. Adaptive jitter buffers adjust their size based on observed network conditions—deeper buffers when jitter is high, shallow buffers when the network is stable.

3. Forward Error Correction (FEC): Instead of retransmitting lost packets (too slow), RTC systems send redundant data that allows receiver-side reconstruction of lost packets. Tradeoff: bandwidth overhead for improved resilience.

4. Selective Forwarding Units (SFU): For multi-party video calls, SFU servers receive streams from each participant and selectively forward to others. Unlike mixing (CPU-intensive), SFUs simply route, enabling massive scale.

5. Congestion Control: RTC-specific congestion control algorithms (WebRTC's GCC, NADA) adapt bitrate in real-time based on network feedback, balancing quality against latency and loss.

Autonomous vehicles embody the full spectrum of real-time requirements—from hard real-time low-level control to soft real-time route planning—within a single complex system.

The autonomous vehicle sensing-acting loop:

Sensors → Perception → Planning → Control → Actuators
  ↑                                              |
  └──────────── Physical world ←─────────────────┘

Each stage has different timing requirements:

Architectural patterns in autonomous vehicles:

1. Sensor Fusion: Combining data from cameras, LiDAR, radar, and ultrasonic sensors to build a robust world model. Each sensor has different strengths (radar works in fog, cameras provide color) and timing characteristics.

2. Hardware Acceleration: Deep learning-based perception runs on GPUs or specialized AI accelerators (NVIDIA Drive, Tesla FSD chip). Inference must complete within strict time budgets for each frame.

3. Safety Envelopes: A separate, simpler safety system monitors the complex autonomy system. If the AI's planned action would violate safety constraints (collision course, excessive speed), the safety system overrides. This safety system has stricter hard real-time requirements than the autonomy stack.

4. Redundancy: Critical systems are replicated:

• Dual power supplies
• Multiple independent computers running the same algorithms (lockstep execution)
• Backup sensors and actuators
• Independent safety monitoring

5. V2X Communication: Vehicle-to-everything (V2X) communication provides advance warning of situations beyond sensor range. Latency requirements vary: safety-critical V2X (collision warning) needs sub-100ms; informational V2X (traffic conditions) tolerates seconds.

The Internet of Things (IoT) and edge computing create real-time requirements at scale—millions of devices that must collect, process, and act on data with timing constraints.

The edge computing motivation:

Cloud computing adds round-trip latency (tens to hundreds of milliseconds). For applications requiring faster response, computation must move to the "edge"—closer to where data is generated and actions are taken.

IoT/Edge timing patterns:

Architectural patterns in IoT/Edge:

1. Computation Hierarchy:

• Device layer: Microcontrollers with millisecond response (filtering, triggering)
• Edge gateway: Local servers with second-scale response (aggregation, ML inference)
• Cloud: Centralized processing for analytics, training, fleet management

2. Event-Driven Architecture: Devices publish events when conditions change rather than polling. Publish-subscribe systems (MQTT, AMQP) efficiently route events to interested consumers.

3. Time Synchronization: Distributed real-time systems require synchronized clocks. Protocols like PTP (Precision Time Protocol) achieve sub-microsecond synchronization for industrial applications.

4. Intermittent Connectivity: Edge devices must function when disconnected from the cloud. Store-and-forward architectures buffer data during connectivity gaps, with local decision-making for time-critical actions.

5. Resource Constraints: Edge devices often have limited CPU, memory, and power. ML models are quantized and pruned for edge deployment; algorithms are chosen for efficiency, not just accuracy.

Aerospace and defense systems represent the most rigorous hard real-time environments, with certification requirements that demand formal proof of timing behavior.

Certification-driven development:

Aviation software must comply with DO-178C (Software Considerations in Airborne Systems and Equipment Certification), which establishes five Design Assurance Levels (DAL):

Architectural patterns in aerospace:

1. ARINC 653 Partitioning: The ARINC 653 standard defines spatial and temporal partitioning for avionics:

• Each partition has guaranteed CPU time slots (temporal isolation)
• Memory protection prevents partition interference (spatial isolation)
• Health monitoring detects and isolates failing partitions
• Used in Integrated Modular Avionics (IMA) architectures

2. Triple Modular Redundancy (TMR): Three independent computers execute the same computation. A voter compares results and uses majority voting to mask single failures. All three must complete before the voting deadline.

3. Dissimilar Redundancy: Going beyond TMR, critical systems use different implementations:

• Different compilers
• Different processors
• Different algorithms (where possible)
• Different development teams This prevents common-mode failures from affecting all copies.

4. Watchdog Monitors: Hardware watchdog timers must be fed by software at a regular interval. If the software misses a deadline (fails to feed the watchdog), the watchdog triggers a recovery action (reset, failover).

5. Byzantine Fault Tolerance: For ultra-critical systems, algorithms tolerate not just failures but malicious/arbitrary behavior from faulty components. Requires 3f+1 replicas to tolerate f arbitrary faults.

Despite their diversity, real-time systems across all domains share common patterns and lessons. Recognizing these patterns accelerates learning and transfers experience between domains.

Technology transfer across domains:

We've explored real-time systems across diverse industries, seeing how common principles manifest in domain-specific architectures. Let's consolidate the key insights:

Module complete:

This concludes Module 1: What Is Real-Time? You now have a comprehensive foundation for understanding real-time systems—from formal definitions and timing requirements to the critical soft/hard distinction and real-world applications across industries.

The subsequent modules in this chapter will build on this foundation, exploring specific technologies and patterns for implementing real-time systems: WebSockets, Server-Sent Events, long polling, push notifications, and real-time architecture patterns at scale.