Querying in event driven microservices

Question

I am trying to get my head around "event driven" microservices. I understood, there are several techniques and patterns, like event notification, event sourcing, CQRS, etc that can help us to achive that. Very simply said, it boils down to some kind of a command has been sent, which leads to a change of the systems state. If the change was applied, the system emits an event. Other services can listen to this events.

But what about querying a microservice for data? Let's say we have an API gateway and some services behind that gateway. Now we want to get a list of all users, which are stored in the user-service. The API gateway could simply send an HTTP GET request to the user-service to receive the list of users. In some kind this might lead to tight coupling, but it seems like the most plausible way.

Can you share your knowlage and experience, when someone should not use HTTP requests for querying a microservice and what alternatives there are.

Answer 1

I think the best way to look at it would be how the system is designed to work with regards to synchronicity. Event driven systems function on asynchronous processes. Like you stated, an event occurs, the state changes, and then another event is emitted. Anything that needs to know about the state change can subscribe to the second event. It's all streamable processing.

Synchronous processing is the opposite. These requests don't change the state; they simply look at the current state (as current as possible). Asynchronous processing will require synchronous processing in order to gain insight into the state and make informed processing. But the thing to note is that they are largely different. And while the processes use each other occasionally, they are separate workflows.

That being said, your question could be answered by saying that if you are wanting insight into the state, HTTP requests are acceptable because the calling application receives that data as part of the request/response cycle. The alternative would be to query the data yourself but that goes against the entire design.