I would say almost half the performance problems I have seen developers and devops managers run into over the last 5-6 years could have been avoided with a bit

I would say almost half the performance problems I have seen developers and devops managers run into over the last 5-6 years could have been avoided with a bit of front loaded queueing theory. When you are doing microservice orchestrations, using an enterprise service bus or a pubsub, or doing multiple asynchronous operations, small delays multiply through the system. Spending a day to model your solution as a queue will give you some ballpark tolerances for lag, queue size, and in particular, RTT through the service. Doing microservice architectures takes a lot of the logic of the problems solved decades ago on the network layer and reinstantiates them at application service layers without those solutions. Request TTL, state, queue flushing, retransmission, shortest path, service availability, 'ping', 'traceroute', etc. If one service crashes, and requests start piling up, you need to clear that queue, and oftentimes your solution isn't built to clear that queue while more requests are coming in and your cache overflows because "keeping state is a next order complexity problem that wasn't specified in the user story." There is an assumption you can just horizontally scale your way out, which has significant compute and administrative costs. I suspect AWS makes a lot of its money as a direct result of those assumptions. Not saying someone needs to be doing new proofs, but some forethought using a handwavy abstraction might provide some insight into the needs of the system under load.