Hacker News Reader

Comment by drm237 | Hacker News Reader

This brings up an interesting issue of scaling. Most larger sites would use a relational database for the backend store (right or wrong) and scale the frontend and backend independently. Because news.yc is using in-memory and disk storage, what are the options available to scale this type of backend architecture?

Assuming load was the issue earlier (which it most likely wasn't) would you move the store to something like a Berkley DB with a network accessible frontend or the newer Memcachedb? Maybe a relational database or even Amazon's new db webservice. If this site was your startup, what would your next move be?

View on HN

In-memory, in-process storage is by far the fastest option (assuming you know a hashtable from a granola bar). A single server can easily handle 1000+ requests/second, which is plenty. The only reason not to do it is if your data doesn't fit in RAM, which is probably not the case for News.YC.

This is a scaling question. Clearly the question is, assuming the current set up is no longer enough, what would be the best way to scale this architecture.

Probably the easiest would be to use memcache for some of the repeated queries, specifically the items that are relatively static, such as the original post or posted item details.

It probably wouldn't help too much on the front page, since that'll update constantly and therefore just be a waste of overhead.

This doesn't really address the issue that there's no centralized information repository. With the content entirely in RAM, to distribute the app to two boxes would require either some sort of message broadcasting system, or re-architecting the data to be stored in some other way.

Agreed that in-memory storage is by far the fastest form of storage available to a single server setup like this. However, I was thinking hypothetically if load was the issue, how would people scale the backend. I was curious if one option would emerge as a favorite.

I disagree that the only reason not to do it is if the data won't fit in RAM. Going to a multi-server setup has many advantages including redundancy for situations such as these, of course, at the cost of increased administration.

These sort of questions have resulted in the traditional web setup you see today with a database backend for storage.

Any reasonably large site will (relatively) quickly exhaust RAM, especially if the same server is handling the requests.

Plus, traditionally there are large sets of data that needs to be searchable, hence the desirability of putting it in a database.

So instead of actually having things in memory, people now use something like memcache to reasonably simulate that for performance.

Reply on news.ycombinator.com