At the recent Microservices Conference µCon London 2017, Greg Young claimed that event sourced microservices is an area that hasn't been explored nearly as much as it should be, but he also strongly emphasized that you should not event source all your microservices. Instead, he recommended looking at individual services and applying the event sourcing pattern to services that actually benefit from it.
For Young, an authority on event sourcing and lead architect behind Event Store, one important design issue when creating a microservices system is whether you should use one database per microservice, or have all your microservices talk to the same database. When storing state, for instance using a relational database, having one or multiple databases does not make any major difference, but when using an event store, he claims that it's drastically simpler to use one event store for several services compared to using one event store per service. The reason is ordering of events, and he refers to Leslie Lamport and his paper Time, Clocks and the Ordering of Events in a Distributed System.
With one event store per service, a service reading events from two or more event stores can neither be sure that all events are read in the same order they were created in, nor be sure that the ordering is the same when replaying the events. With a number of services using one event store, there is a guaranteed ordering, and the ordering is deterministic. This is called linearizing, a technique that will not make a system more scalable, but will make it easier to reason about, which Young believes in most cases is more important than potential scalability issues in the future.
Young claims that linearizing will work for most systems, even when handling well above 10k events/s. With really high throughput, maybe up to 250k events/s, then it may be a good idea to look for another design.
With operations spanning more than one microservice, correlation and causation identities can give great benefits. When one service raises an event which other services listen to, and then raises their own events, it can cause a cascading flow of events through the system, which can be very hard to follow. But, by adding three identities (uuids) to events- a message id, a correlation id and a causation id, this obstacle can be overcome.
An event always gets a unique message id when created. By setting the correlation id for an event to the same correlation id as the event that caused it to be raised it will be possible to find all events in an event flow that belong to the same root cause, and by setting the causation id to the message id of the event that caused it to be raised, it will also be possible to see the order in which the events were raised.
This ability to see the overall message flow in correct order can be very useful in understanding and finding the cause when an error occur. This technique can also be used in a system that is not event sourced. By adding an auditing service that listens to all events raised by the services and stores them, you can get the same possibilities.
Other subjects Young discuss in his presentation include in memory services, replication models and geographic distribution.
Next year’s conference is scheduled for November 5-6, 2018.