Off topic: a guaranteed way to start a flame war in an automotive forum is to state that there is no such thing as "backpressure" and that fluid dynamics and the continuity equation fully explain why restricting exhaust pipe diameter results in increased performance.
It gets even more fun when the back pressure is in the intake side (aka boost). I was tuning a friends turbo 300zx after he upgraded to a bigger turbo. At the same boost levels as before the car was slower. He was confused. After a quick chat around turbos, air speed, etc., I simply told him we needed to crank up the boost. Some tweaks to timing and fuel maps and this thing could now really fly.
its still pretty easy to screw up. how does the system you're using handle back pressure and how does that behavior affect other parts of your system. if you have two systems that each do back pressure, are you certain that the system remains closed? that is if those systems aren't coupled implicitly through the scheduler or explicitly in some other way, then you can balloon state or drop results between them.
I have often found limiting the buffer size as a simple way to communicate back to producers that more work can't be taken. Then what happens is all a producer strategy to drop work or wait for a period of time then drop or just hold onto the work until the buffer has a clear space. Its about the simplest message from consumer to producer you can do and how games tend to do backpressure and how Go channels work.
Off topic: a guaranteed way to start a flame war in an automotive forum is to state that there is no such thing as "backpressure" and that fluid dynamics and the continuity equation fully explain why restricting exhaust pipe diameter results in increased performance.
Light the fire and then sit back and enjoy.
It gets even more fun when the back pressure is in the intake side (aka boost). I was tuning a friends turbo 300zx after he upgraded to a bigger turbo. At the same boost levels as before the car was slower. He was confused. After a quick chat around turbos, air speed, etc., I simply told him we needed to crank up the boost. Some tweaks to timing and fuel maps and this thing could now really fly.
I wanna tell them how torque vs horsepower isn't real, horsepower is all that matters unless your transmission sucks
(Not to say that the width of the power band doesn't matter)
I feel like backpressure was a common topic in 2010, and now modern event driven system design just naturally handles this issue.
Not all modern systems are event-driven. The large-scale systems I've worked on have plenty of RPC.
Backpressure applies to regular request-based systems just as well.
As in: should your request handler try to do retries if one of the dependent services fails?
I recall this in the form of buffer bloat.
its still pretty easy to screw up. how does the system you're using handle back pressure and how does that behavior affect other parts of your system. if you have two systems that each do back pressure, are you certain that the system remains closed? that is if those systems aren't coupled implicitly through the scheduler or explicitly in some other way, then you can balloon state or drop results between them.
I want to believe
I have often found limiting the buffer size as a simple way to communicate back to producers that more work can't be taken. Then what happens is all a producer strategy to drop work or wait for a period of time then drop or just hold onto the work until the buffer has a clear space. Its about the simplest message from consumer to producer you can do and how games tend to do backpressure and how Go channels work.