Once microservices hit real scale, event-driven architecture — built on streaming pipelines — stops being optional and becomes the only way things hold together. Teams decouple, systems absorb bursts, everyone ships independently. It works great, until an event gets stuck three services back and nobody notices.

"Where's my event?" is the question that eventually lands on someone's desk — usually the team furthest downstream, closest to the customer, with the least visibility into where things actually broke. I ran into this building a high-stakes, customer-facing system at the end of a long, multi-team streaming pipeline. When something upstream failed a handshake or an event stalled mid-flight, we didn't get an error — we got a support ticket and a customer asking why something they were expecting never showed up. And here's the part that's easy to miss: if no team ever finds that lost event, every individual team still looks fine on paper. Nobody's dashboard shows red. But the company loses anyway — real revenue, and slower-to-notice, real trust.

This talk digs into why that gap opens up in event-driven systems, and what it takes to close it — leveraging streaming to treat reconciliation as infrastructure in its own right, not an afterthought. I'll share the patterns and tradeoffs that mattered most, from spotting silent loss early in a live event stream to making sure the fix itself doesn't develop blind spots of its own. And why this isn't just a niche problem — anywhere a service or an agent sits downstream, consuming events, tool outputs, or context it didn't generate, it's exposed to the same gap, and needs the same kind of answer.