This blog is a preview of our session at Sirus Connects on October 9, 2026, where we share concrete strategies for changing streaming data systems while they keep running: idempotency patterns, backfilling gaps and deploying without losing events.
Speaker:
Don't try to prevent failure. Design for recovery.
Every system needs to change eventually. New requirements come in, bugs surface, better tools become available. The normal approach is to schedule a maintenance window, take things offline, and fix what needs fixing.
But what if that’s not an option? What if the data keeps flowing, consumers keep expecting results, and there’s no pause button anywhere in sight? That is what it means to replace planks while the ship is sailing.
In a streaming platform, data arrives continuously from sources that don’t wait to be asked. Consumers downstream expect results to keep coming without interruption. Every change you make, whether a planned upgrade or an emergency fix, has to happen while the stream keeps running on either side of it.
All the ways it can go wrong
Over the years I’ve hit most of the ways this can go wrong. A source goes quiet for six hours and comes back with a dump of everything it missed, in a slightly different format than before. A bug in a transformation goes unnoticed for days, quietly corrupting output that other systems have already started relying on.
A component needs upgrading, but the upgrade requires a brief outage, and that outage has to happen while the stream keeps running. A third party changes their data format mid-stream without warning.
Each of these is a different problem. Each one has a different answer.
Why streaming isn't batch
This is where streaming differs from batch. In batch, if a job fails you run it again. The data was always there, patient and waiting.
In streaming that safety net is gone. Your source might not buffer indefinitely. Your window to recover can be measured in hours, not days. The stakes are different, and the solutions have to be too.
Design for recovery
The principle I keep coming back to: don’t try to prevent failure, design for recovery.
In practice that means treating your raw incoming data as the only source of truth, and everything you derive from it as something that can be rebuilt when things go wrong. It means making your processing idempotent, so you can replay data safely without creating duplicates or corrupting previously correct outputs. It means catching problems early, before they propagate. And it means accepting that some downtime is unavoidable, and designing around it rather than pretending otherwise.
These aren’t theoretical principles. Each one came from something actually breaking.
What I'll show at Sirus Connects
At Sirus Connects I’ll walk through the failure modes and the concrete strategies I use to handle them: from idempotency patterns to backfilling gaps to deploying changes without losing events. No best practices without context.
If you’ve ever stared at a gap in your time series wondering how it got there, or sat on a deployment because you weren’t sure you could recover if it went wrong, this talk is for you.
Come find me at Sirus Connects on October 9.
Want to follow this live?
Join this session at Sirus Connects on October 9, 2026, from 14h15 to 15h. Register and secure your spot.
Can’t make it? Reach out to us, we are happy to share our experience and discuss how to make your streaming platform resilient to change.
