

Ask HN: Scaling considerations when building Minimum Viable Product - ketanb

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?
======
minalecs
Do you need to worry about scaling ? No.

If you can prove your idea, execution, and model, then you will be able to
worry about scaling then.

------
milkshakes
Best scaling advice I've ever read:

[http://teddziuba.com/2008/04/im-going-to-scale-my-foot-
up-y....](http://teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html)

~~~
ketanb
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?

------
chuhnk
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.

------
damoncali
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.

~~~
byoung2
_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.

~~~
barfoomoo
Which framework do you use?

~~~
byoung2
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.

------
ketanb
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.

