Another motivating factor that feeds back into a desire for efficiency and scalability in service backends is the trend towards freemium models. In the freemium model, the conversion rate of users to dollars is the driving force behind success. If you have an insanely popular app, but only one in twenty-thousand users spends a dime, you’re gonna be hurting. Given a monthly operating cost of X, it would require an average revenue per paying user - ARPPU
- of X / (monthly active users * conversion rate).
Unfortunately, the operating costs (X) are dependent on the MAU - as more users check out a service, more infrastructure is needed to handle the load. This can lead to a situation that prevents success if your service doesn’t scale cheaply! The smaller the units of scaling resources are, the more closely you can match the change in volume of usage.
Say you had a system that was built to scale up, then scale out. You have a couple of monstrous and very expensive servers that handle everything. When demand increases to the point that more resources are needed, there’s a very discreet rise in operating costs to support another monstrous server. If you have a system that is built to scale out, on the other hand, the effects on operating costs when the necessary resources cross a threshold is less pronounced. This gives you some agility from a financial stand point, and frees up more revenue to use elsewhere!
Or, as a poorly drawn back of the envelope graph:
Here, the curvy line represents resources required to serve users in a timely manner, the dotted lines represent actual available resource capacity. The space between the two is waste.