The author is here. Thank you for a thorough reply, these are both valid points. I have been thinking about them before implementing the algo and this is where

The author is here. Thank you for a thorough reply, these are both valid points. I have been thinking about them before implementing the algo and this is where my thoughts are at the moment: PID tuning is a complicated task, but what I found is that the parameter space where the coefficients are "good enough" is quite big. Certainly much bigger than where the coefficients are "perfect". A lot of times changing the coefficients has some effect on the transient state parameters such as rise[1] and settling[2] times, but they still result in a robust controller that drives the value to the setpoint. I agree, this might not be acceptable for some applications where the transient time is very important, but often times even making a P controller does a fairly good job controlling the system. In this case it means a single coefficient that is relatively straightforward to tune. I’m pretty sure our simulation was not perfect as we scaled down time to speed up the testing cycles, but we didn’t spend too much time on it. It was just a test script to get the initial values of the coefficients. When we got those we could deploy it to staging environment and run a load-testing tool to fine-tune them. Improving the existing system would mean coming up with a way to broadcast the change quickly enough, and that would add more dependencies and synchronization overhead despite being time consuming. Right now everything is done with standalone loosely-coupled services that communicate with each through APIs and cache the results. This is a very good point and I think I’m going to add these details to the post. [1] https://en.wikipedia.org/wiki/Rise_time https://en.wikipedia.org/wiki/Rise_time [2] https://en.wikipedia.org/wiki/Settling_time https://en.wikipedia.org/wiki/Settling_time