Systems
What Kafka Actually Solves
Not 'messaging.' Decoupling, replay, and absorbing a spike your database was never going to survive — like 170K–430K ICU vitals a day.
The wrong reason to add Kafka
If you need a job queue for emails, Redis or a table is enough. Kafka shows up when producers and consumers shouldn't share a clock: monitors emit every second, the dashboard needs the latest point now, and Postgres should see a 1-minute aggregate — not every sample. That's the ICU Companion path. Kafka is the buffer and the log, not the database.
Decouple, then replay
Producers write and forget. Consumers can crash, scale, or reprocess from an offset. That's the feature: history is replayable. A Redis pub/sub message that nobody was listening for is gone. A Kafka partition still has it. When a consumer lags, you scale that consumer group — you don't ask the bedside device to slow down.
Absorb the spike
The database has a QPS ceiling. Kafka does not care that 400k events arrived today. Consumers drain at a rate Postgres can take: 1-second processing on the hot path, 1-minute persistence, Redis for the last known state. If you skip the log and write every vital to SQL, you will melt the primary on a busy ward. That's not a hypothetical. That's why the topic exists.
Takeaway
Use Kafka when you need an ordered, durable stream you can replay and when the writer must not wait on the reader. If you don't need replay or fan-out, you bought a distributed system for a queue. That's the expensive kind of overkill.