Designing a Event Bus for your Microservices
Synchronous http requests has it’s merits but alternatives are worth exploring in microservices world.
Designing systems in a async event-driven fashion with well defined bounded context will guide your services to be independent, isolated and decoupled from each other.
Designing microservice on just synchronous http calls creates coupling between them that will affect productivity of the teams.
Once you choose your messaging platform you will need to get a client for producing and consuming messages in your microservices, something like this.
Invoices API — A microservice exposing invoice resources
Reports Service — A microservice which listen to domain events from other services. Store data in a denormalized fashion and expose a API for retrieving the aggregated data.
Notifications Service — A microservice responsible for sending notifications like SMS, Push, SOAP
As you can see dealing with the client approach has some drawbacks like:
- Boilerplate code for publishing and consuming events spread around services
- If in a near future you decide to change your messaging system you must to refactor all NSQ references over services
To fix this let's define a package with an well defined interface for emitting and listening for events.
Extract a Event Bus Wrapper
Let's create a tiny wrapper around the messaging platform where package users can easily emit and listen to events.
Now let's refactor our code for using this new abstraction. The event bus package was designed to reduce boilerplate and remove the pain when emitting and listening for events in your microservices architecture.
With the event bus package created, let's refactor our services for using this tiny abstraction.
Invoices API — After an invoice is created emits an event and let other services know about that "fact".
Reports and Notification Service — both listen to invoice events
Message-Driven architecture is the main element when designing microservices and reactive systems. With this tiny abstraction developers know how to emits and listen to domain events without effort.
If you decide to use an messaging platform like Kafka for storing these "facts" all you need to do is publish a new version of your event bus package.
Show me the code
Feel free to take a look at the event bus package https://github.com/rafaeljesus/nsq-event-bus