I don’t think the content of the article is necessarily great, but I’m fascinated by the issue described in it.
Most systems that make it to the news these days are horizontally scalable, however most of the systems that I read about assume a fairly equal distribution of activity per unit that has been scaled over. But what is the unit you should actually scale over? Can you determine that upfront (independently of if it’s worth it to implement it upfront)? What happens if your service is massively assymetric in its usage?
I think these questions are really fascinating.
I think the answer in the article comes down to two things: denormalized counter and facebook datacentres.
Usually you look for the smallest coherent chunk that has independent data. For example for a SaaS CRM system each customer is isolated, so a customer is going to be your unit.
Then if you’re using a relational database or other system where only vertical scaling is really practical, you estimate how big a customer is likely to get and see if that’ll exceed what you can fit on a machine. If it is too big, then you need to think about how you’re going to design it to scale horizontally instead.
With NoSQL you have similar questions, but at the row level rather than the entire database level.
It depends on how much you like the users who are costing you more to serve (I wrote a blog post on this recently - http://www.robustperception.io/unlimited-costs-limited-revenue/). If they’re effectively abusing the system and not making you money, then ToS and throttling are options. If they are users you want to keep, then in the first instance you rebalance your sharding (if any) and then look at how you can scale though better data structures or maybe caching if the proportion of problematic users is small.