Distributed transactions are one of those problems that sound simple in theory and humble you in production. When I was tasked with architecting an event-driven customer onboarding system at ThoughtWorks, I knew we needed something more resilient than two-phase commits and more structured than "just use eventual consistency." We chose the SAGA pattern with Kafka as our event backbone — and the journey taught me more about distributed systems than any textbook. The system needed to coordinate multiple microservices — identity verification, account creation, compliance checks, and notification delivery — in a way that was reliable, observable, and recoverable. A failure in any step couldn't leave a customer in a half-onboarded state. The SAGA pattern gave us a framework for orchestrating these steps with compensating transactions, while Kafka provided the durable, ordered event stream we needed. This post shares the real lessons from that build: the architectural decisions that paid off, the edge cases that bit us, and the patterns I'd use (and avoid) next time. If you're a Java or backend engineer working with distributed systems, this is the practical guide I wish existed when I started.

Why Not Two-Phase Commit?

Designing the SAGA: Orchestration vs. Choreography

Kafka as the Event Backbone

Handling Failures: Compensating Transactions in Practice

Observability and Debugging

What I'd Do Differently

Have questions about event-driven architecture? Reach out — I'm always happy to talk distributed systems.