I end up doing hand-wavey explanation of things that abuses the terms of Big O because then it suddenly seems like its a real, valid argument, but what I really

I end up doing hand-wavey explanation of things that abuses the terms of Big O because then it suddenly seems like its a real, valid argument, but what I really wish I could just say it how it is and have people understand and respond correctly: "If the time the server spends is proportional to number of requests coming in, and the number of requests coming in is proportional to user engagement, and we expect user engagement to grow over time by a rate also proportional to user engagement -- but the amount of server time we have available to serve requests is constant (there's no designed solution to scale horizontally) then we have a problem." Not a surprise problem that suddenly appears on the day where we run out of resources, but a problem to solve today, right now, because we are already over-committed by the nature of this design, and not a problem we can solve by making the single node any bigger to start out with... But many are seemingly strongly conditioned by education (whether that includes CS or not) to only pull out certain techniques when a problem presents itself in a pre-packaged familiar way, so if I whip out Big O, folks are suddenly able to see that they're on the losing side of a bet pitting a flat line against a curve.