This pattern shows up when you want to update clients of a system in such a way that they don’t need to contact the source system in order to do further work. A customer management system might fire off events whenever a customer changes their details (such as an address) with events that contain details of the data that changed. A recipient can then update it’s own copy of customer data with the changes, so that it never needs to talk to the main customer system in order to do its work in the future.
An obvious down-side of this pattern is that there’s lots of data schlepped around and lots of copies. But that’s less of a problem in an age of abundant storage. What we gain is greater resilience, since the recipient systems can function if the customer system is becomes unavailable. We reduce latency, as there’s no remote call required to access customer information. We don’t have to worry about load on the customer system to satisfy queries from all the consumer systems. But it does involve more complexity on the receiver, since it has to sort out maintaining all the state, when it’s usually easier just to call the sender for more information when needed. https://martinfowler.com/articles/201701-event-driven.html
An effect of the Event-Carried State Transfer pattern is that the system inherently becomes eventual consistent.
Sacrificing strong consistency is not uncommon in distributed systems as they must balance consistency, availability, and partition tolerance. It’s impossible to have all three as per CAP theorem and partition tolerance and availability are often prioritized when designing scalable systems.
- Deloitte1
The pattern seems to very much align with the preference of duplication over coupling in a microservices architecture