In the previous post, I looked into running transactions in a layered architecture. Now, let’s consider transactions that need to span more than one service.
If you work with microservices, a time may come when you need a transaction running across them. Especially if the way they are split was an afterthought (the unfortunate but likely scenario). Service A calls service B, which calls service C, and if something goes wrong at the end, the system becomes inconsistent.

ThreeDotsLabs' platform is  dedicated to providing insights and resources for software engineers and technology enthusiasts. Through articles, tutorials, and open-source projects, ThreeDotsLabs offers insights into software development best practices, design patterns, and emerging technologies. Developers can learn about building scalable architectures, microservices, and cloud-native applications to solve real-world problems effectively.

Three Dots Labs

The post discusses the complexities of using distributed transactions in microservices with Go. It warns against using distributed transactions due to their complications and instead suggests alternatives like embracing eventual consistency and using the outbox pattern. The post also provides a detailed implementation approach for using event-driven architecture with Redis and Watermill in Go, including handling events asynchronously and ensuring data consistency. It emphasizes the importance of correct service boundaries and provides guidance on testing and monitoring event-driven systems.

Distributed Transactions in Go: Read Before You Try

<p>The key takeaway from this article “Let’s face it: your microservice boundaries are likely wrong if you consider using a distributed transaction.”</p>
