How can event-driven architecture be applied to this example?

user_3592550 0
Viewed 790

I am unsure how to make use of event-driven architecture in real-world scenarios. Let's say there is a route planning platform consisting of the following back-end services:

  • user-service (manages user data and roles)
  • map-data-service (roads & addresses, only modified by admins)
  • planning-tasks-service (accepts new route planning tasks, keeps track of background tasks, stores results)

The public website will usually request data from all 3 of those services. map-data-service needs information about user-roles on a data change request. planning-tasks-service needs information about users, as well as about map-data to validate new tasks.

Right now those services would just make a sync request to each other to get the needed data. What would be the best way to translate this basic structure into an event-driven architecture? Can dependencies be reduced by making use of events? How will the public website get the needed data?

microservices apache-kafka event-driven rabbitmq architecture
3 Answers

Cosmin is 100% correct in that you need something to do some orchestration.

One approach to take, if you have a client that needs data from multiple services, is the Experience API approach.

Clients call the experience API, which performs the orchestration - pulling data from different sources and providing it back to the client. The design of the experience API is heavily, and deliberately, biased towards what the client needs.

Based on the details you've said so far, I can't see anything that cries out for event-based architecture. The communication between the client and ExpAPI can be a mix of sync and async, as can the ExpAPI to [Services] communication.

And for what it's worth, putting all of that on API gateway is not a bad idea, in that they are designed to host API's and therefore provide the desirable controls and observability for managing them.

Update based on OP Comment

I was really interested in how an event-driven architecture could reduce dependencies between my microservices, as it is often stated

Having components (or systems) talk via events is sort-of the asynchronous equivalent of Inversion of Control, in that the event consumers are not tightly-coupled to the thing that emits the events. That's how the dependencies are reduced.

One thing you could do would be to do a little side-project just as a learning exercise - take a snapshot of your code and do a rough-n-ready conversion to event-based and just see how that went - not so much as an attempt to event-a-cise your solution but to see what putting events into a real-world solution looks like. If you have the time, of course.

user_390940

The missing piece in your architecture is the API Gateway, which should be the only entry-point in your system, used by the public website directly.

The API Gateway would play the role of an orchestrator, which decides to which services to route the request, and also it assembles the final response needed by the frontend.

For scalability purposes, the communication between the API Gateway and individual microservices should be done asynchronously through an event-bus (or message queue).

However, the most important step in creating a scalable event-driven architecture which leverages microservices, is to properly define the bounded contexts of your system and understand the boundaries of each functionality.

More details about this architecture can be found here

user_27873640

Event storming is the first thing you need to do to identify domain events(a change in state in your system). For example, 'userCreated', 'userModified', 'locatinCreated', 'routeCreated', 'routeCompleted' etc. Then you can define topics that manage these events. Interested parties can consume these events by subscribing to published events(via topics/channel) and then act accordingly. Implementation of an event-driven architecture is often composed of loosely coupled microservices that communicate asynchronously through a message broker like Apache Kafka. Free EDA book is an excellent resource to know most of the things in EDA.

Tutorial: Even-driven-architecture pattern enter image description here

user_17951450
Related