1

Still getting to grips with EDA. Suppose in your system you have an Order Service, which first needs to check if the customer's account has enough credit from the Account Service. There are multiple ways of doing this:

  1. You could achieve this purely with Events over a bus:

Order Service (marks order as pending) --> OrderRequestedEvent --> Account Service --> CreditApprovedEvent --> Order Service (marks order as confirmed)

  1. You could also use a Command over a bus (request/response?):

Order Service --> ApproveCreditCommand --> Account Service --> ApproveCreditResult --> Order Service

  1. But could you not also just use an Api?

Order Service --> /account/123/credit --> Account Service --> HttpResponse --> Order Service (checks credit amount)

My question is, can you use all of these approaches in EDA, or must everything be only events or commands? Are some approaches more suitable than others?

If option 3 goes via an API gateway, I'm struggling to see why it would be any more coupled than the others. Yes it assumes there is definitely something somewhere which will respond to that GET, but then they all assume a follow up action (otherwise the order would sit unconfirmed forever).

3

Patterns are like tools in a toolbox: you pick the right tool for the job and often you'll need more than one. Event-driven architecture simply means that at a high level, your application responds to incoming events (and possibly produces its own), but it certainly doesn't mean that everything has to be an event.

There is nothing wrong with an API call if that's the simplest way for you to check the customer's credit. In fact, I would say it's the preferred solution since you are expecting a response. Or if the credit check is asynchronous, I'd go with the command bus solution. An event is probably not the right model for this since events are meant to be fire-and-forget notifications.

| improve this answer | |
1

Well, obviously option 3 is not event driven, but as casablanca already told you, there's no need to be dogmatic "just because".

However, there's indeed a drawback which leads to tighter coupling, which is downtimes:

If your user calls service A which calls service B via an API or other synchronous means, and service B happens to be down, service A will fail and the user will get an error message, which is not exactly nice.

If you use an event based request-response pattern in the same situation, the request will be on the bus, service B will be restarted, process the event and send back the response. All the user will know is, that it took slightly longer to get a response, which normally is no big deal.

Note that this argument only holds true, if you have serious monitoring and application control in place (you should, if you go the microservice approach) where a service in an unavailable state is immediately discovered and restarted.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.