-
Tags:: #Software Architecture 🗞️Articles
- Queues are not a miracle.
-
Link:: Queues Don’t Fix Overload
-
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.
-
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
-
-