In my work as a software engineer working on distributed systems we tend to think about these things in terms of scaling limits, bottlenecks, limiting factors, tightest constraints, etc.. For example, a system might be limited by a single resource hitting a scaling limit (maybe the CPU is maxed or the network between two servers is saturated or something else), and then that is the only thing that matters to fix at that moment because nothing else will change the scalability of the system since it’s the limiting factor. Working on anything else is wasted effort in the short term.
I’ll just add that the real world is messy, and often the constraints are not independent. For example, you might have two systems that send work back and forth to each other, and they may work because they are in equilibrium, and scaling one and not the other, even if it appears to be the limiting factor, may not work because it will cause effects in the other service that will seem to suggest that it’s the limiting factor, and if you change the second service you end up in the same state, so really the issue is that the limiting factor exists as a result of an interaction between those two systems that isn’t naturally a single constraint but emerges in the running system.
FWIW, this is why my job is more like being a zookeeper or vet than being, say, a mechanic: the interactions are so complex I can’t model or know them all, so I instead have to rely on fuzzier methods even if I can get very precise when I can narrow the complexity down enough to make that possible.
I actually started to talk about finding loosely-coupled constraints in an earlier draft of the post, but that quickly turned into the entire skill of model-building. That was when I decided to just go with the games, at least for this post.
In my work as a software engineer working on distributed systems we tend to think about these things in terms of scaling limits, bottlenecks, limiting factors, tightest constraints, etc.. For example, a system might be limited by a single resource hitting a scaling limit (maybe the CPU is maxed or the network between two servers is saturated or something else), and then that is the only thing that matters to fix at that moment because nothing else will change the scalability of the system since it’s the limiting factor. Working on anything else is wasted effort in the short term.
I’ll just add that the real world is messy, and often the constraints are not independent. For example, you might have two systems that send work back and forth to each other, and they may work because they are in equilibrium, and scaling one and not the other, even if it appears to be the limiting factor, may not work because it will cause effects in the other service that will seem to suggest that it’s the limiting factor, and if you change the second service you end up in the same state, so really the issue is that the limiting factor exists as a result of an interaction between those two systems that isn’t naturally a single constraint but emerges in the running system.
FWIW, this is why my job is more like being a zookeeper or vet than being, say, a mechanic: the interactions are so complex I can’t model or know them all, so I instead have to rely on fuzzier methods even if I can get very precise when I can narrow the complexity down enough to make that possible.
I actually started to talk about finding loosely-coupled constraints in an earlier draft of the post, but that quickly turned into the entire skill of model-building. That was when I decided to just go with the games, at least for this post.