When speaking about event-driven architecture in the past, people have told me it’s not for them because they build web applications and/or REST APIs. That made me think of a phrase from functional programming (functional core, imperative shell) and I wrote a short blog post about how there’s still value in being event-driven.
>In this case, the goal of the event-driven architecture isn’t that everything is event-driven. It’s that any service that’s exposed to requests that demand a response can handle them on its own.
But then, if service A can handle the user's request all on its own, without delegating any part of it to a dependency service, that's a purely request-response system. Responding to a request doesn't require emitting a single event. If responding to a request does involve posting an event and then waiting for a counterpart event, you still have the temporal coupling.
As long as you expect _something_ to happen in reaction to your event, even implicitly, you are always coupled to the service that listens for the event in some way. After all, what do you do if it doesn't happen (in time)? Communicating through the event channel removes the direct runtime coupling between the two bespoke microservices and replaces it with direct coupling to the event channel. The B microservice no longer has to be available at the time of A's request/event, but that's all that you get (and it is only an improvement because the event channel is a much more mature program than our own crappy B microservice). As mentioned in a comment on the blog website, you could also achieve the same kind of indirection through some sort of "asynchronous RPC" like temporal.io, by polling changes in a shared database, etc.