Event collaboration

Event collaboration describes an architectural principle that works well together with an event-driven publish/subscribe architecture.

Consider the following example that uses the regular request/reply communication pattern—a user requests the booking service to book a ticket for a certain event. Since the events are managed by another microservice (the EventService), the BookingService will need to request information on both the event and its location from the EventService. Only then can the BookingService check whether there are still seats available and save the user's booking in its own database. The requests and responses required for this transaction are illustrated in the following diagram:

requests and responses

Now, consider the same scenario in a publish/subscribe architecture, in which the BookingService and EventService are integrated using events: every time data changes in the EventService, it emits an event (for example, a new location was created, a new event was created, an event was updated, and so on).

Now, the BookingService can listen to these events. It can build its own database of all currently existing locations and events. Now, if a user requests a new booking for a given event, the BookingService can simply use the data from its own local database, without having to request this data from another service. Refer to the following diagram for another illustration of this principle:

BookingService using the data from its own local database

This is the key point of an event collaboration architecture. In the preceding diagram, a service almost never needs to query another service for data, because it already knows everything it needs to know by listening to the events emitted by other services.

Obviously, this architectural pattern works extremely well together with publish/subscribe. In the preceding example, the EventService would be the publisher and the BookingService (potentially, among others) the subscriber. Of course, one might flinch at the fact that this principle will inevitably lead to redundant data being stored by the two services. However, this is not necessarily a bad thing—since every service constantly listens to events emitted by the other services, the entire dataset can be kept (eventually) consistent. Also, this increases the system's overall resiliency; for example, if the event service suffers a sudden failure, the BookingService would stay operational since it does not rely on the event service to be working anymore.