In terms of control theory, the order "delay" is actually a simple filter. What leads to bad outcomes is exactly the described scenario, when the control response too fast for the system, overcorrecting and oscillating. Increasing the order filtering dampens the control response.
It strikes me that a problem with this analysis is with the modeled example system itself. The assumption that stock should follow immediately preceding demand is valid but typically wrong.
Pursuing the intellectual mechanics of a system is obscuring the error of the wrong system!
Instead stock levels should take into account lead time, historical seasonal demand, and a subjective value. The observation and order frequency should be in months not days.
While computing allows near “real time” everything, that doesn’t mean it should necessarily be applied.
Just-in-time thinking needs to take the reality of the system (in this case the supply chain) and other factors like hedging opportunities?
It’s a simplified example of a broader principle. This structure shows how oscillation can emerge from a very simple system and how it can be remedied by adjustments of the delays. Oscillating systems are very much a thing and this explains why.
By the way, what you said about stock levels is correct, of course, but doesn’t necessarily avoid oscillations. See, all of these metrics are feedback-based as well. With a delay. How much history do we take into account? Are account lead times influenced by delivery times. This is a classic problem in system dynamics: where do we draw the system boundary? Since everything is connected to everything, the right thing to do is to model the entire universe. Since this is not practical, we draw a line _somewhere_. _Where_ exactly does not matter much as long as the resulting model is useful.
It applies to software engineering too in things like autoscaling. I’ve seen many DDOS outages caused not by the attack itself but the wave of autoscaling that takes things down (often well after the actual attack ended).
I think the source of confusion is that the "response delay divisor" isn't a delay at all. This parameter is the inverse of amplification. If you dampen a signal more then it will oscillate less.
Do people actually do systems design with control theory? I know the authoritative question to possibility - yes, my company does it. But I'm wondering about say, an industry standard formalism to it, such as like how DDIA is household
Somewhat, but for distributed systems I’ve found game theory to be more useful. Which does end up looking like high-order control theory in many cases.
It’d be nice but in my experience I’ve seldom seen that much thought put into it, even with actual literal control systems. Unless you’re doing something interesting in robotics or aerospace, most stuff gets solved with logic sequences and maybe some PIDs.
In terms of control theory, the order "delay" is actually a simple filter. What leads to bad outcomes is exactly the described scenario, when the control response too fast for the system, overcorrecting and oscillating. Increasing the order filtering dampens the control response.
For people interested in the related math, "Nonlinear Dynamics and Chaos" by Steven Strogatz is a great book! Pdfs abound online.
Or if you want something lighter but still fascinating "Sync" by Steven Strogatz is also good :)
Reminds me of this piece I read on hacker news over a decade ago:
https://mcfunley.com/whom-the-gods-would-destroy-they-first-...
It strikes me that a problem with this analysis is with the modeled example system itself. The assumption that stock should follow immediately preceding demand is valid but typically wrong.
Pursuing the intellectual mechanics of a system is obscuring the error of the wrong system!
Instead stock levels should take into account lead time, historical seasonal demand, and a subjective value. The observation and order frequency should be in months not days. While computing allows near “real time” everything, that doesn’t mean it should necessarily be applied.
Just-in-time thinking needs to take the reality of the system (in this case the supply chain) and other factors like hedging opportunities?
It’s a simplified example of a broader principle. This structure shows how oscillation can emerge from a very simple system and how it can be remedied by adjustments of the delays. Oscillating systems are very much a thing and this explains why.
By the way, what you said about stock levels is correct, of course, but doesn’t necessarily avoid oscillations. See, all of these metrics are feedback-based as well. With a delay. How much history do we take into account? Are account lead times influenced by delivery times. This is a classic problem in system dynamics: where do we draw the system boundary? Since everything is connected to everything, the right thing to do is to model the entire universe. Since this is not practical, we draw a line _somewhere_. _Where_ exactly does not matter much as long as the resulting model is useful.
It applies to software engineering too in things like autoscaling. I’ve seen many DDOS outages caused not by the attack itself but the wave of autoscaling that takes things down (often well after the actual attack ended).
maybe even a simple arraylist required some tweaks to avoid wasting allocation on some insert/delete patterns
I think the source of confusion is that the "response delay divisor" isn't a delay at all. This parameter is the inverse of amplification. If you dampen a signal more then it will oscillate less.
Reminds me of The Beer Game https://en.wikipedia.org/wiki/Beer_distribution_game
See also the bullwhip effect
https://en.wikipedia.org/wiki/Bullwhip_effect
Do people actually do systems design with control theory? I know the authoritative question to possibility - yes, my company does it. But I'm wondering about say, an industry standard formalism to it, such as like how DDIA is household
Somewhat, but for distributed systems I’ve found game theory to be more useful. Which does end up looking like high-order control theory in many cases.
It’d be nice but in my experience I’ve seldom seen that much thought put into it, even with actual literal control systems. Unless you’re doing something interesting in robotics or aerospace, most stuff gets solved with logic sequences and maybe some PIDs.
This all sound like PID tuning guide
Beside system theory, were there other fields studying the relationship between sampling data rate en stability ?
very interesting read, key takeaway, delays are not always bad! Definitely something to think about in 2026
[flagged]