Many people associate event streaming with “huge volumes of data” or immediately with a specific tool. To me, it is less about performance and more about an architectural pattern for clean, evolvable systems, regardless of whether the data volume is extreme.
The principle in simple terms
Rather than having System A call System B directly (meaning both must be available at the same time), A writes an event to a shared stream of events—think of it as a traceable log. Other systems read these events and react when they are ready.
An event might be something like:
- “Measurement received”
- “State changed”
- “Alarm triggered”
Why this is especially interesting for IoT and edge
As soon as producers are not reliably available at all times—for example, sensors at the network edge, on-premises systems, an unstable cellular network, or deliberately throttled connections—an event-based approach becomes particularly valuable. Producers can buffer data locally and transmit it safely later, while consumers process it independently. Depending on the context, this can start very lightweight at the network edge and later evolve into a central, traceable event log. The pattern is what matters: buffer, transmit reliably, and continue processing independently, even when connections or systems are temporarily unavailable.
Why this improves architectural quality
-
Less coupling, more flexibility. In classic architectures, chains form quickly: A calls B, which calls C. If one part is slow or fails, everything gets stuck. With streaming, A stays lean and the other systems react independently. New requirements often mean “new consumer” rather than changes in multiple places.
-
Changes become easier because history is part of the system. When a new analysis, product feature, or integration is added later, existing events can be processed again (replay) or historical periods can be filled in (backfill). This reduces special-case solutions and makes the system less fragile.
-
Data contracts become explicit. In many projects, interfaces are a creeping cost driver: unclear fields, implicit assumptions, “that’s how it has always been.” Event streaming forces clear data contracts: which fields exist, what they mean, and how versioning is handled. It may seem like more effort at first, but it saves more time later than it costs.
-
Traceability is built in. An event log is often the best answer to “what happened when?” This is especially valuable when multiple systems are involved.
Question for the group
In your experience, where do systems fail more often: because of too much coupling, poor interfaces, or operations and observability?