BT

Your opinion matters! Please fill in the InfoQ Survey!

Designing Event Sourced Microservices

| by Jan Stenberg Follow 9 Followers on Nov 12, 2017. Estimated reading time: 2 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT