How to expose an API using the traditonal request-response style while internally it handles it in event driven way (pure or partially event driven), given that if callback style may not be possible due to the circumstance ?

In event driven microservices, the microservices react to events, very often it may go through several microservices before the whole process is completed.

Suppose the triggering point is an HTTP request via an API (or restful API / reactive API), this API may not know when the whole process is completed. And once the result is known, there is also issue of how to response back, as the original http request is on one thread, while the consumer listener is in another thread (suppose the final result is got via consuming events)

I have googled on this topic but seem no ideal solution so far, like polling on the result may work, but it also result in repetitive query and the response time may be bounded depending on the rate of retry.


1 Answer 1


There are several options.

One would be to use a long lived connection; this would be either a websocket or http2 stream. In either case, the request arrives over that connection and is kept open till the result is available; and then the result is pushed to the client.

The other option is client's pull - client keeps asking the server - "are you done?". If you have just one server, that's ok. If you have a cluster, then the situation is tricky, you are not guaranteed to connect to right server.

There are several options as well.

One would be to have "sticky" connections. After a client submits a job, the "work-in-progress" result has ip/name of that particular server and the client keeps pulling from that specific server.

Second option is quite similar: you client connects to any server, but that server can proxy the request to right worker.

Another option: you will have to have some kind of cache or queue to be able to read the result from. When the worker is done, they write the result to a cache or publish it to a specific queue.

It is important to consider pull vs push. Pull does not look fancy, but it is dead simple. If vast majority of your pull requests does not require many retries, go with that. Otherwise consider push with all extra complexity around that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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