Event Driven Microservices Communicating Using Feeds — part 2
I wrote part-1 of this blog describing microservices. This is the part two where I will talk about the event-driven architecture(EDA) and event feeds.
Before we go into EDA let’s look something else.
Service Orchestration Vs Service Choreography:-
So finally, We have got a bunch of microservices and now we need to figure out how will they communicate with each other.
The first option is making a point to point contact between microservices. This is known as Service Orchestration. Point-to-point means that one service calls the API of other services resulting in a dependency graph. Adding, Changing or removing services from this graph is hard since you have to be aware of each connection among the services. Below is a dependency graph for Service Orchestration.
The second option is commonly known as Service Choreography, where point to point interactions are ruled out. This is a model where an upstream service publishes events to an event channel, while downstream services subscribe to those events. In this way, the services are loosely coupled with each other. In this model, there is enough flexibility of adding, changing and removing services as long as they are able to publish or listen events. Below is a dependency graph for Service Choreography.
Event Driven Architecture (EDA):-
An event-driven architecture consists of multiple services which communicate to each other in an asynchronous way. Each service publishes an event whenever an update has been made to its data. Other services will be subscribing to these events and react. This is a service choreography model.
There are three main component of EDA:-
Event Source:- Event source or event generator is the service where an update action is performed. It will generate an event for that update transaction.
Event Channel:- This is the mechanism which is used to transfer the event information from the source to the consumers.
Event Consumers:- These are the other services which are interested in the update transaction and will be listening to any update.
Event flow in EDA
There are different mechanisms to notify consumers about the events. We will discuss Publish-Subscribe-Pattern and Event Feeds.
Publish-Subscribe-Pattern:- The publish-subscribe pattern is a messaging pattern where event source called as publishers, publish the events to a communication channel categorized in different classes. This communication channel keeps a track of the consumers of these events, known as subscribers. The communication channel sends the events to different subscribers. The subscribers can choose to listen one or more than one class of messages and only receive messages that are of interest.
The benefit of this pattern is, that the subscribers and publishers don’t really need to know about each other. This has a major disadvantage, After an event is received, it cannot be replayed, and new subscribers do not see the event.
Event Feeds:-
In this pattern, the event source puts events to an append-only event-log called as feed. This feed is strictly ordered and acts as a time-series having multiple events. Clients don’t subscribe to these feed instead a client can read from any part of the stream. The clients are responsible for moving to the right position in the event-feed. This means a new client can join at any point in time and fetch all the data it is interested in, and even existing clients can replay the events.
An implementation of the event feeds used in our project can be found here. Below are the properties of the event feed :-
- Events are ordered by the time they were created from oldest to newest.
- The feed is an append-only log. Once an entry is made to the feed, it cannot be changed.
- The feed can be designed as a multipage document, where each page consists of N events. The pages will contain urls of “next-page” and “previous-page” so that clients can navigate.
- A new client will start reading the feed from very start of the page. It will keep navigating using next-page URLs till the end of the feed.
- The clients need not to be connected all the time, a client can pause and resume the synchronization. This helps to the remote clients which are not always connected.
- In any case if a client looses the data, it can always read the event feed from start or from a specific place.
That’s all for now. Hope to write something new soon.
