Hacker News new | ask | show | jobs
by mononcqc 5527 days ago
No, this doesn't break the async philosophy. The synchronous sequence of calls is done by a question/reply made out of 2 asynchronous calls. It's just that simple to make something synchronous, as opposed to turning something synchronous asynchronous (by using a queue).

By doing this you are not limiting the queue to the size of 1. If you have N producers, you can have more than N elements in the queue, but the idea is that each producer can only enter them one by one, with the agreement of the consumer. Nothing would stop the consumer from accepting a thousand of them before waiting before replying, therefore slowing down the producer. The idea is just to limit the rate at which you accept queries by tying it to the speed of the consumer.

If this is not enough, you can look at things like the jobs tool (https://github.com/esl/jobs) to work with scheduling.

By the way, you're mistaken on the idea of message sending always succeeding. The idea is that you will never error out because of trying to send a message (send and pray), not that the message will make it to destination. If you want any guarantee that the message made it, then you need that acknowledgement async message being sent back to you.