Scalability for dummies

Alex Barrera has a very interesting post about how frustrating it is to figure out that you have a problem and how much trouble it is to fix it after the product is live.

I am there, I am suffering the redesign phase (twice now). It’s hard, it’s lonely, it’s discouraging and frustrating, but it needs to be done. I just wrote this post so that outsiders can get a glimpse of what is it to be there and how it affects the whole company, not just the tech department. Scalability problems aren’t something you can discard as being ONLY technical, it’s roots might be technical but its effects will shake the whole company.

The post actually reminded me of this post by Marton Trencseni which talks about the phases of improvement in scalability architecture a product goes through and digs a little deeper into what could have prevented it.

For startups or for companies which are just prototyping new ideas, their goals can sometimes be just to “test the waters”, and the product owners don’t care much about allocating/reserving enough resources for engineering to build it the “right way”. And there is a good reason for that as well, since a lot of prototypes ( or early products ) die off soon after launch because of issues completely unrelated to scalability. Its hard to figure out if you want to test the idea first or devote a lot of resources to get it done the right way from day one.


Popular posts from this blog

Latest Global COVID-19 stats

Brewers CAP Theorem on distributed systems

The pain of Load balancing applications