Architecture
Designing Real-Time Systems Without Melting the Database
Separate the hot path from the source of truth. Interpolation and Redux on the client matter as much as Kafka on the server.
Real-time is two problems
Getting the event in is a streaming problem. Showing it without jank is a UI problem. On ICU Companion, vitals arrive every second. If React re-renders the whole tree on each point, the pipeline's throughput is wasted. Redux patches the monitoring view. Interpolation between samples keeps the graph readable instead of stair-stepping. That's frontend work with production consequences.
Hot path vs source of truth
Redis holds the last known state and cached large reads. Postgres holds 1-minute aggregates you can audit. The dashboard never queries the primary for every tick. SSE (or a similar push) is enough when the server is the authority and the client is a subscriber — WebSockets are for when both sides write. Most monitoring UIs are not chats.
What fails first
Usually the consumer, then the UI, then the disk. Backpressure at Kafka, a cache in front of fat reads, and a client that doesn't subscribe to more beds than it can paint. Load-test with the real message rate, not 10 events a second in staging.
Takeaway
Durability and speed stop being opposites when the hot path and the system of record are not the same store. If they are, you will choose one under pressure — usually the wrong one.