How I built an app with 500,000 users in 5 days on a $100 server

There's a lot of flak over poor comparison to photos and self-promotion. However, his overall point is still true: just putting a little effort in upfront with assumption you will succeed can prevent these problems. My baseline for evaluating this is "Did they do at least as well as someone who spent 30 seconds on Google?" Short version: doing better wouldn't have required a ton of thinking.

Here's what 30 seconds Googling "highly-scalable chat architecture" gave me:

http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html

https://engineering.riotgames.com/news/chat-service-architecture-servers

http://doc.akka.io/docs/akka/1.3.1/scala/tutorial-chat-server.html

Note: Like to have seen numbers for field-test of the above in the article. Yet, it would've gotten someone thinking.

http://lsirpeople.epfl.ch/nbonvin/dl.php?f=chat-report.pdf

http://doc.utwente.nl/68325/1/imp-pasm.pdf

Previous times doing this for web services led me to highscalability.com with many architectures to imitate with fairly mature software components available. At this point, the common ones should practically have templates for "enter metrics expected here" then click to deploy.

I read the story a while ago and was waiting for the criticism in the comments. Now one comment [0] already pointed out many of the issues of the article.

What's been mentioned in other comments but not explained in great detail is the database design, so I want to expand that:

The right way (TM) to do databases is to design a solid schema to keep data integrity and then apply indices and caches depending on your application needs. To be honest his application seems super simple to cache top-down, so a few lines inside the nginx config (which seems to scare him for some reason) would probably do. But if you use a real database (also TM) you can go bottom up, too:

1. solid schema with constraints

2. indices depending on your application

3. stored procedures, database views

4. some non-relational cache like MongoDB to cache denormalized data

5. maybe something in memory

6. (application)

7. nginx caching

He started with 4. What he did is not a solid database design to brag about, instead he hardcoded a cache inside his application. If he wants to scale his application vertically or horizontally he will have big problems, because he misses a point at the beginning which contains the truth on which everything else is build upon. If he starts scaling up and then wants to change his schema he is basically in hell.

What he did is nothing bad. It is exactly "the MVP way". MVP is not about slow or buggy software but a really small feature set and applying YAGNI. MVP is nothing bad, he seems to have great sucess with it! What I am criticising is not how he build his software but what he wrote about it, comparing it to a much harder case and thinking it has something to do with good design.

[0]: https://news.ycombinator.com/item?id=12135748

>> Where would I have put my images? In the database: MongoDB. It would require no configuration and almost no code.

Why... would anyone actually do that in anything more than a classroom example for an application like the one described? Amazon S3 and similar services have very decent libraries for pretty much every popular programming language, why would you re-implement that?

>> MVP and scalability can coexist

I'd replace that with less catchy but probably more correct 'experienced devs can make more scalable mvps with little extra cost, if any'. MVP doesn't mean lets just go silly and make the quickest and dirtiest decision imaginable.

It's a matter of experience to recognize potential problems and the respective potential solutions, and program accordingly. SQL schema is a pretty good example. Often it makes a big difference in scaling and often you can design the initial schema to be much more scalable with some experience and a few moments of planning.

But this would have been totally disastrous under any type of serious load. Even if I would have simplified the above query to only include three conditions/sorting operations, it would have been disastrous. Why? Because this is not how a database is supposed to be used. A database should query only on one index at a time, which is impossible with these geospatial queries.

On the database side, I separate the snaps into a few different collections: all snaps, most liked snaps, newest snaps, newest valid snaps and so forth.

Pardon my ignorance, but don't most databases have some method of handling these issues?

(defining multiple indexes for use, having support for geospatial data, having support for like, subsections of the existing dataset, etc?)

I thought that the main goal was to offload the developer's code's logic onto the performant database, as opposed to offloading the database's logic and caching onto the developer's code? is the former not practical?

Here is my take on this:

1. MVP vs. scalability: While building scalable product/s right from the MVP stage is generally a good idea, it may not be particularly beneficial or applicable to most scenarios. I mean

a) how many typical startups happen to scale to 500k or 1M users within days from launch?

b) most founders would be needing an MVP mainly for market validation, as a proof-of-concept and for the purpose of attracting seed/startup funding

c) many founders - especially non-coders - may not have the luxury/resources to have scalability built in to the MVP

2. The original story goes to reconfirm my belief, based on multiple past experiences going back many years, that database continues to remain a (huge) bottleneck for web apps with high traffic volumes and max possible database optimization (right from config tune-up to table structure design/normalization to query optimization) can pay huge dividends in most cases.