2 ms·
Their alternative: "To make stuff usable, a proper idempotent API with end-to-end principles in mind will make it so these instances of back-pressure and load
by LanceH 3y ago
Their alternative:
"To make stuff usable, a proper idempotent API with end-to-end principles in mind will make it so these instances of back-pressure and load shedding should rarely be a problem for your callers, because they can safely retry requests and know if they worked."
Is to ignore requests and make the caller implement their own queue, apparently.
- xyzzy_plugh 3y agoIt's turtles all the way down. At some point, it's _not really_ a queue. For example imagine a computer program to fetch the contents of a list of URLs. Perhaps it makes some number of parallel requests. If the URLs are hard coded, e.g.: fetch("https://news.ycombinator.com/") fetch("https://bbc.co.uk/") fetch("https://archive.org/") ... When the maximum concurrency is reached (which could simply be 1) and all requests are blocking, then back-pressure is applied. The callers wait before submitting more work. In this example the queue is the code, and the program counter acts represents the head of the queue. I wouldn't regularly refer to that as a queue. Perhaps instead it reads a list of entries from a file. The queue's state can be represented by file offset. And so on. Computers are by definition carry out sequences of operations. A sequence can be viewed as a queue. Everything is a queue. So yes, ignore requests and make the caller implement their own queue _is a completely correct take_ in a sense, but I don't find it productive.