Case study 02
Modernizing a critical event pipeline without breaking downstream systems
Moving a tightly coupled integration path onto a durable event architecture — preserving delivery, tolerating downtime, supporting replay, and giving every consumer a safe path from old to new.
Context
A critical business workflow depended on events flowing through an integration path that had accumulated coupling over time. It worked, but changing or maintaining any one part meant understanding assumptions that crossed service boundaries.
The goal was a more durable event-driven architecture, without turning the migration itself into a production risk.
Problem
Swapping the transport was the easy part. The hard part was preserving the behavior the rest of the organization depended on while the machinery underneath it changed.
Event migrations are defined by their failure and transition states rather than their happy path, so the design had to start there.
Questions the design had to answer
- What happens while a consumer is unavailable?
- How long can events safely stay buffered?
- How does a restarted service know where to resume?
- What if the migration is only partly complete?
- How can downstream systems move independently?
- How do we tell a delayed event from a lost one?
- How do we roll back without duplicate or inconsistent processing?
- Which signals tell us reality has drifted from the design?
My role
I designed the target architecture and the migration path, and built it: the event boundary, the buffering and replay model, the transition, and the monitoring around it.
Decisions
01Decouple producers from consumers
A clear event boundary let downstream services evolve without upstream producers needing to understand how they worked.
TradeoffThe boundary is one more component to own and operate. It pays off once consumers need to change on their own schedule.
02Treat buffering and retention as guarantees
Temporary downtime shouldn’t turn into data loss. Upstream buffering and retention windows were designed in and checked, not left as operational accidents.
TradeoffRetention has to comfortably exceed the longest pause you plan for, so it becomes something to verify before every maintenance window.
03Preserve replay
Consumers could resume from a known position after downtime or migration work, instead of guessing where they had left off.
04Move incrementally
Old and new paths ran side by side where needed, so the transition never depended on a single irreversible cutover.
TradeoffTwo paths mean deciding how duplicates are handled and when the old path is truly done.
05Watch the boundaries, not just the processes
A healthy process doesn’t mean a healthy pipeline. Monitoring was built to make delayed, failed, or stalled event processing visible.
Execution
Define the boundary
Separate event production, durable transport, and consumption.
Run both paths
Old and new intake side by side while consumers moved over.
Plan the window
Shutdown and restart order, checkpoints, validation, owners, and rollback paths — written down before any production change.
Cut over
Consumers moved to the new path, resuming from known positions.
Watch the signals
Delayed, failed, or stalled processing made visible at the boundary.
Outcome
The migration left a cleaner boundary between systems and made failure behavior explicit. Services can be stopped on purpose without treating every pause as an event-loss emergency, recovery behavior is understood, and replay and retention are part of how the pipeline is operated.
Just as important, the production transition could be reasoned about ahead of time, and later changes need less coordination across systems.
Lessons
- Architecture migrations succeed or fail in the spaces between components.
- Changing the transport is easy. Keeping trust in the system while everything underneath it changes is the real work.
- Know your retention and replay guarantees before you depend on them.