Events driven systems: takeaway nuggets for developers (Part 1)

I’ve been working on events driven system for almost 2 years. Within this time I learned many of the concepts, patterns, and practices for designing events driven architecture. In this story I will share very simple points that will help you understanding this architecture.

1# The world is asynchronous:

This is what happens when you go to Starbucks:

• You order ->
• The cashier dispatch your order by writing your name and drink on the cup ->
• While barista is preparing your drink you are doing the payment ->
• Now your drink is ready or you are going to wait for few minutes until it is ready

Notice here that it may be fine for this process to be synchronous if everybody drinks Black coffee as it takes almost 5 seconds preparation: just pour a coffee in the cup. But Frappuccino takes an effort and time to be prepared and the process is going to be so slow.

Some systems has many independent services that collaborate with each other. As the number of services grows gradually, the web of synchronous interactions grows with them and issues (like Cascading failures) might appear due to high load and services outages.

One of the solutions is to make sure SLA of any service is more than the SLA of the whole system. Other solution is to break down that synchronous call into multiple asynchronous calls through a message broker.

#2 Service interaction through three way: command, event, and query:

• Command is any synchronous operation: in the Starbucks example above it is processing the payment. In command a response not always required.
• Query: a request for data. Queries don’t change state but we always expect a response.
• Event: events are used either for: transfer data, or notifications. Usually called “fire and forget” because we don’t expect a response. In Starbucks example above an event is when the cashier put the cup with your name in the queue.

This categorize systems into two categories:

• Request-driven systems: tightly couples services because functionalities are placed inside services.
• Events-driven systems: as data generated and moves between services the change happens at the end of any subscriber who is interested in this event.

3# No single service owns the whole process:

Each service owns a small part, and these plug together through a chain of events. So each service does its work, then raises an event denoting what it did.

No service know the existence of any other service. This has an advantage. The service can change without affecting the whole process as long as you it generates the same event. For example, in the Starbucks example: the cashier (payment service) knows only that he should react to orders and create payment processed events and put the cup in the queue. If you pay by credit or cash, the generated event is the same.