Is it a good practice at all?

E.g. we have an API layer which has to call some service when it receives a request, and the work which that service has to do must not be done concurrently. If there would be no API layer one would just use a queue and dispatch tasks there and the service would consume and process those one by one.

But what if because we need to respond from API we can't use such async approach? What comes to my mind is that one could still use a queue, but this looks messy - API layer would need to dispatch the task to the queue, hold the request, poll the task processing status (in the db or queue or whatever) and eventually respond when it's processed.

Is such solution really a bad design? What would be a better one?

  • 1
    zguide.zeromq.org has detailed descriptions of patterns to deal with this kind of situation. I know it's long, but you might find it worth a read. Jan 30, 2019 at 18:38

2 Answers 2


There are two basic ways to deal with this, both of which can use a queue, and probably even should, but can be implemented in various ways. Note that there are many implementations out there, and you should probably use one unless you have a particular reason not to (e.g. you're just researching the subject for now). Those two ways are:

  1. Blocking
  2. Non-blocking


That last bit was a joke. The difference between the two is (beyond implementation details) whether your caller tries to do something else in the meantime, nothing else.

If you use a blocking technique, then your call doesn't return until it either gets a result, or it concludes (either from being told, or just guessing) that there will never be a result.

If you use a non-blocking technique, then your function returns as soon as it's queued the request, and you either have to check for a result every once in a while (which, it's worth noting, might itself be done by checking another queue!), or establish a handler that'll be called when a response arrives.

Honestly, neither is guaranteed to be better than the other, and when you consider further possibilities like the fact that non-blocking I/O can be used on *nix OSes by giving O_NONBLOCK to the fcntl() function, or the idea of sending a piece of javascript to a server for that server to use as a filter in it's response chain (possibly to decide if the request is even valid anymore), or the possibility of initially waiting to see if there's a quick response and occasionally rechecking non-blocking style for a while afterwards, the difference between the two tends to... smush a little bit.


A response to the caller is obligate in API, what you could do is when you receive a request, you keep the received information in an internal async process and send back a default response (200) just to advice the client the request has been received. Internally in BackEnd you can process the process normally, and send the answer back via some message mechanism.

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.