Microservices is a really becoming a famous architectural pattern that most of the new software written these days, just apply them. One of the most important differentiation between the traditional web services and micro services pattern is the amount of common stuff across different subject areas. This calls for a discussion on how Eventual Consistency pattern is mandatory for successfully implementing micro services.
Generally in a micro-service pattern, the API’s are split in to small subject areas. For example for a CRM application, the subject areas are
- Customer information – like name, address, email, phone
- Appointment information – which customer, sales person, when, where
- Relationship management – sales/manager, what products, interests
- Campaign data – offers, deals etc
Then micro-services are built for each of the subject areas. The microservices are logically and physically separated from each other. ie there is no sharing (code, database, component etc) between any of these micro services of these subject areas. Pictorially its looks something like this.
Applying Eventual Consistency Pattern
In Micro-services, there is no data that is shared across the micro services. In order to synchronize the data across these isolated storages of these services, we need to apply the eventual consistency pattern. You can read more about applying the pattern correctly here. The simpler way we can achieve consistency across these micro-services is through Event Sourcing pattern.
Event sourcing is a process of capturing application state changes in the form of events. An example of events are customer created, customer updated, Deal created, etc. Other systems listen to these events and they take relevant action. You can read more about event sourcing here.
Event sourcing is the new way of storing changes to systems and help in making micro-services eventually consistent. These patterns together form well maintainable, reliable and scalable systems in the modern world.