Asynchronous Boundaries and Back Pressure


Summary

Non-blocking back pressume is a useful way to avoid common problems at the asynchronous boundary between autonomous agents.

Vanising Train

A significant component of reactive programming is asynchronous boundary between the message sender and receiver. The problem is that the receiver might not work as fast as the sender and thus fall behind. When this happens the sender can block (blocking), the event bus can throw messages away (losiness), or the receiver can store messages (unlimited message queue). None of these are ideal.

In response, a key concept from reactive systems is non-blocking back pressure. Back pressure allows queues to be bounded. One issues is that back pressure can't be synchronous or you lose all the advantages. Another is that if the sender doesn't have anything else to do (or can't do it easily) then you effectively get blocking.

Picos, as implemented by KRL, are lossy. They will queue requests, but the queue is, obviously finite, and when it reaches its limits, the event sender will receive a 5XX error. This could be interpreted as back-pressure, a NACK or sorts. But nothing in the krl event:send() action is set up to handle the 5XX gracefully. Ideally, the error code out to be something the sender could understand and react to.


Please leave comments using the Hypothes.is sidebar.

Last modified: Thu Oct 10 12:47:18 2019.