5 ms·
Technically true, but it doesn't make sense from a business perspective. Anticipating and accounting for every scaling issue costs a lot of money. Most business
by bottled_poe 10y ago
Technically true, but it doesn't make sense from a business perspective. Anticipating and accounting for every scaling issue costs a lot of money. Most businesses would decide that satisfying 90% of scenarios is sufficient.
- user5994461 10y agoBusiness is irrelevant once you're sure that the service will go into production AND will have some amount of users. It's known that some things will break from time to time (e.g. servers, hard drives, networking). If you've designed the application poorly so that a single minor failure can snowball to the entire system, it's guaranteed that your site will fall apart periodically, costing you lots of money each time. At this point, the best technical AND business converge to "pick an option that can sustain [minor] breakages". Either you've done it like that from the start, or you're in the process of rewriting/redesigning your site.
- bottled_poe 10y ago> Business is irrelevant once... Not really. In the case described they had accounted for some maximum number of users and instead got 50x that number. It is reasonable to design a system which handles just some planned number as long as there is a strategy in place to manage a situation beyond those limits. In this case the strategy was to apply engineering effort. That seems like a valid risk management plan to me.