- Tags:: #[[Software architecture|Software Architecture]] #🗞️Articles - Queues are not a miracle. - Link:: [Queues Don’t Fix Overload](https://ferd.ca/queues-don-t-fix-overload.html) - Highlights: - But someone should have picked what had to give:** do you stop people from inputting stuff in the system, or do you shed load**. Those are inescapable choices, where inaction leads to system failure. - When people blindly apply a queue as a buffer, all they're doing is creating a bigger buffer to accumulate data that is in-flight, only to lose it sooner or later. **You're making failures more rare, but you're making their magnitude worse**. - This is clearly a reference to #[[antifragile|Antifragile]]. - And you know what's cool? **If you identify these bottlenecks you have for real in your system, and you put them behind proper back-pressure mechanisms, your system won't even have the right to become slow.** What you may have is customers that are as unhappy (because in either case, they can't do what your system promises right), but with proper back-pressure or load-shedding, you gain: id:: 4ac66fb5-f451-4bc1-93f9-bd2cb793fe97 - Proper metrics of your quality of service - An API that will be designed with either in mind (back-pressure lets you know when you're in an overload situation, and when to retry or whatever, and load-shedding lets the user know that some data was lost so they can work around that) - Fewer night pages - Fewer critical rushes to get everything fixed because it's dying all the time - A way to monetize your services through varying account limits and priority lanes - You act as a more reliable endpoint for everyone who depends on you