An Event-driven architecture (EDA) could be a candidate to realize a communication-basis between microservices and an approach to get the services mostly decoupled. The architectural pattern exist for a couple of years and has been described in papers and articles like [1,2,3].
However in this and the following post I won’t repeat the theory in detail, I’d rather like to describe how to sketch an EDA based system and just sometimes use quotations of the papers above – like [1]:

An event is a notable thing that happens inside or outside your business.

Some things to consider

One core-idea is to get rid of call-stacks [2], data updates and coupled systems.

Call stack based interaction allows one method to invoke another, wait for the results, and then continue with the next instruction.

Sounds familiar? Sure, sounds like synchronous method calls, a central point which knows the steps to walk through and a central data repository.

… EDA does not provide any of these functions – the interaction is limited to one component publishing an event that can be received (usually with a delay) by one or more other components.

Sounds like asynchronous communication between components, unknown state of data and complex to realize.

One impact on the architecture is the constraint to work with immutable data, respectively to start working with events. Events are the preferred way to share information between system-components and have to be idempotent. Data’s state changes are just announced as new events and events themselves are never updated.

Event-driven systems work differently, almost to the inverse. Systems so not query systems for information but instead keep their own copy of the required data and listen to updates as they occur.

In the following series of posts I’d like to sketch step by step a system with a lightweight Event-driven architecture.

Event Channel – The Infrastructure Backbone

Event based system rely on a communication channel like a message bus. Event generators can publish events to a topic and consumers, which are interested into a certain type of events, can subscribe to the corresponding topics. Currently I don’t care if a topic transports only one type of events or whether a topic can transport a bunch of event-types. Let’s start with one type and postponing the definition of the term event-type and what an event contains in detail.
Anticipating that masses of events will occur if any state-change is published, the backbone should be reliable, fast, scaleable and such things. Searching for such criteria in the web, Apache Kafka [4] seams to be an interesting choice. However any other message-bus like ActiveMQ, RabbitMQ a.s.f. would work too – especially in this sketching context it’s ok to decide spontaneously and preferably the implementation should be technology ignorant.
Luckily docker images for such message busses already exist, so it could be an easy start. You could try one of the images available on Docker hub [5] to get one of them up and running in a few minutes. If you don’t like docker other systems would work too. But for sketching purposes docker in combination with a ready to play image works quite nice.
I have to underline the results of this and the following sketches don’t reflect a production ready system yet – that would need more efforts and everything is just running on a single notebook.

The 2nd part of this series is:
How to drive Event Generation

References:

[1] Event-driven Architecture Overview – Event-Driven SOA Is Just Part of the EDA Story
[2] Programming Without a Call Stack – Event-driven Architectures
[3] Focusing on Events
[4] Apache Kafka
[5] Docker Hub