In synchronous APIs, the blocking code plays a crucial role in preparing the response that is sent to the client. However, in the asynchronous design, non-blocking is key. A queue and workers can be helpful in achieving non-blocking code. A server can have multiple workers running in parallel who can exhaust the contents of a queue and work on them. Whenever a client requests an operation through an asynchronous API, the server can put that request in a job queue, and all the workers can pick up a task whenever their turn comes.
This approach can offload an API server and focus on its business logic instead of getting blocked on parallel/independent tasks such as sending emails, contacting third-party services, and so on.
A few use cases of queuing are as follows:
- Compress images and email the final result
- Automatic back pressuring (limiting the load on the server to predictable amounts)
To explain this concept in detail, let's formulate an example and try to implement it.
Let's develop an asynchronous API server that can perform two different kinds of jobs:
- Logging given information to the database
- Sending an email
The condition is that it should not block other operations. The API should return a Job ID ticket to the client who can use that information to fetch the running information of the job.
Before jumping into the implementation, we should know about a few basics of enabling queuing to our service. We can implement queue/worker from scratch, but there are many good open source queuing systems such as RabbitMQ or ZeroMQ to choose from.
We, as part of implementing the preceding problem, will use RabbitMQ due to its popularity and the maturity of Go bindings.