03 — Real-Time Systems
Design for the moment information changes.
Some products cannot wait for refresh.
Markets move. Teams collaborate. Alerts fire. Devices report. Streams continue.
Real-time products require the interface, transport, state model, reliability strategy, and infrastructure to be designed together.
Fast isn't the same as real-time.
The difficult part is not opening a WebSocket.
It is deciding what happens when messages arrive late, connections disappear, events reorder, users reconnect, state diverges, permissions change, or thousands of updates compete for attention.
That's where architecture becomes experience.
Capabilities
- WebSockets
- WebRTC
- Live dashboards
- Streaming interfaces
- Notifications
- Event-driven systems
Ideal when
- stale data has a measurable cost
- multiple people act on the same record at once
- reconnection currently means a full page reload
- alert volume has outgrown human attention
- the interface updates faster than anyone can read it
Relevant work
Fictional demo engagements
Related reading
-
Architecture decisions your users eventually feel
Database boundaries and caching strategy sound like implementation details until they become loading states and support tickets.
-
Real-time UX is a state-management problem before it's a networking problem
Opening the socket takes an afternoon. Deciding what the screen means when messages arrive out of order takes the rest of the project.