3 ms·
I view this the opposite way around. Message queues and asynchronicity are an alternative to backpressure as described. If I synchronously hit some service th
by benjaminwootton 14y ago
I view this the opposite way around. Message queues and asynchronicity are an alternative to backpressure as described.
If I synchronously hit some service then I need to build facilities into the service to say that it's too heavily loaded, and perhaps handle those responses on the client.
If I pop some job onto a message queue or asynchronous endpoint, things will just slow down for a while. Which is normally as good a way as any as soaking up load.
- squarecog 14y agoHow do you keep the message queue from unbounded growth?
- jreichhold 14y agoArrival rate and dequeue/processing time are the keys here. Unbounded queues are easy.. Just limit the queue size. Of course this isn't what the user of the service wants and leads to a very bad experience
- rdtsc 14y agoAs someone already replied, message queues under constant load can grow unbounded. > If I synchronously hit some service then I need to build facilities into the service to say that it's too heavily loaded, and perhaps handle those responses on the client. Most of the time, you have to have timeouts when there is a synchronous API across the network. In a large system ideally you'd want to reflect the level of loading back to the input source so the source can slow down sending the data. Think of TCP, tcp works this way on a small scale. One way to fix the problem is to leverage that to actually open a TCP stream and send data that way. The sender will slow down accordingly. Now if you know that your load is not constant, so there are periods of high activity when inputs are generated then you can try and absorb (and amortize) those high volume peaks using asynchronous queues.