[scottlamb]

It's unclear to me how a PID controller applies to the problem described in the article: having each client choose a subset of backend tasks in a way that will be stable for a long time. PID controllers deal with a scalar setpoint, scalar measured variable, and scalar control output and adjust frequently. How is that helpful at all in choosing this subset? It's certainly not a straightforward application of standard literature that the authors completely ignored, as suggested by siscia's grandparent comment.

> So in this example, it might be that you distribute your requests to servers based on how over or under loaded the servers are.

They had a working approach to distributing requests to servers, described at the beginning of the article. It's sessions (aka connections or channels in Google's literature) they're focusing on.

Responding also to siscia's grandchild comment:

> Or you can spin up more machines. The integral and derivative part will tell you when spinning up more machines or when to tear down the one you already got!

You're describing something like Google's autopilot, which I just linked to in another comment. A PID controller might make sense there, but it's only tangentially related to the problem described in this article.

[siscia]

I personally was thinking to apply a controller to each client machine and making it control the number of connections to the backend.

You can control for the P90 latency and increase or decrease the number of connections to backend machines.

Similarly the backend can decide to drop connections if it see that the latency of the reply is too high, or if the CPU is too high or whatever other metrics make sense.

I don't see if a similar system would ever reach a stable-enough state.