Every company as they start getting traction faces challenges about scaling databases, scaling website/applications, etc. I would like to ask HN about what was your scalability approach? When building minimum viable product release, did you built it with scalable architecture in mind or rebuild the site ground up once it got more traction?
It is a nice article but doesn't help understand what are the options available to people. For the discussion, let's assume , it is just a bad code and has nothing to do with what tools are used. In those cases where it is not easy to go back and fix the code, what are the options people are using?
Scaling to a million page views or so a day is not difficult. With the technologies available at hand there is less need for big hardware to do it. For instance you could grab a few Amazon EC2 nodes, use one as a balancer to the others. Grab nginx for the web server, proxy to your application, varnish for static caching. Alot is going to be determined by the way you access the database, there is no need to go to nosql when mysql can scale beyond your needs. Limit your queries, only select the data you need instead, use indexes, be smart about table structures.
If you ever do get to facebook/twitter like traffic, you'll probably have money and entire ops team to deal with it.
Scale is almost always something you should ignore completely while building an MVP. It is trivial to build a web app that can handle enough users to prove the product. There are exceptions, but they're very rare.
Scale is almost always something you should ignore completely while building an MVP
I disagree. There is no reason you can't build in best practices from day one. You don't have to go overboard thinking about it (since you probably won't need to scale much), but you can plan ahead for it. For example, on most projects I use a PHP framework similar to Symfony that is based on Doctrine ORM and uses Smarty templates. If a project grows, Doctrine lets you easily add memcached for all queries. If it grows more on the data side, I can easily tweak the setup to use master and slave DBs or even a circular replication cluster. If it grows more on the traffic side, I can change a CNAME setting to move static files to a CDN. I can also set up Varnish in front of the app server. I can put a load balancer in front of the app server and rsync the code base across dozens more app servers. All of this can be done simply by tweaking a few config files. Of course 99% of the time I'll just need 1 or 2 servers, but I can scale at will when the time comes.
I wrote it myself, drawing inspiration from the best parts of Symfony. I use Doctrine for ORM and database abstraction, and Smarty for templates instead of the raw PHP that Symfony uses. I also ditched Symfony's static file caching in favor of Smarty's. I kept basically the same YAML config structure from Symfony...no need to fix what wasn't broken.
What happens when site pickup and scaling issue becomes real. How would you deal with such situations? Do you rewrite the site or try to keep scaling up as much as possible.
If you can prove your idea, execution, and model, then you will be able to worry about scaling then.