In this video, we'll look at some techniques for evolving events by analyzing a specific use case in a banking fraud detection system.

When building a distributed system, developers are often faced with something known as the dual-write problem. It occurs whenever the system needs to perform individual writes to separate systems that can't be transactionally linked. This situation creates the potential for data loss if the developer isn't careful. However, techniques such as the Transactional Outbox Pattern and Event Sourcing can be used to guard against the potential for data loss while also providing added resilience to the system.

In this video, Wade explores the process of decomposing a monolith into a series of microservices. You'll see how Tributary bank extracts a variety of API methods from an existing monolith. Tributary Bank wants to decompose its monolith into a series of microservices. They are going to start with their Fraud Detection service. However, before they can start, they first have to untangle the existing code. They will need to define a clean API that will allow them to move the functionality to an asynchronous, event-driven microservice.

How do we know whether Event-Driven Microservices are the right solution? This is the question that Tributary Bank faced when they looked at modernizing their old fraud-detection system. They were faced with many challenges, including scalability, reliability, and security. Some members of their team felt that switching to an event-driven microservice architecture would be the magic bullet that would solve all of their problems. But is there any such thing as a magic bullet? Let's take a look at the types of decisions Tributary Bank had to make as they started down this path.

Back in the 2000s, code lived in one execution thread. Database queries, user interactions, and data pipelines were all managed by the same processes. The problem? Everything was interconnected and interdependent. Fixing one thing might break another. Releases were all or nothing. We call this monolith hell. Your ticket out? Microservices.

Back in the 2000s, code lived in one execution thread. Database queries, user interactions, and data pipelines were all managed by the same processes. The problem? Everything was interconnected and interdependent. Fixing one thing might break another. Releases were all or nothing. We call this monolith hell. Your ticket out? Microservices.