[holdupadam]

I haven't really had to scale a system up like this before. As a freelance web developer moving to a bigger slice? on linode has been good enough for any wordpress blog or simple site.

That said, I didn't realize what a massive undertaking it could be like this describes.

Anyone had any similar scaling challenges with less conventional web-stacks? Im particular I'm wondering how a node.js/mongodb stack would do this same thing.

[moe]

I have scaled many systems in the past and the easy answer is: Know what you're doing or hire someone who does.

There is no blanket answer because applications and workloads differ. E.g. MongoDB has a number of documented issues under high load (esp. high write load), in some scenarios they can be worked around with reasonable trade-offs, in some they can't and Mongo needs to be replaced.

If there's one general thing to say about scaling then that you scale applications, not stacks. The stack will usually change in the process.

[fvbock]

> If there's one general thing to say about scaling then that you scale applications, not stacks.

very true! which is why i think it usually is a good idea to analyze how you could split up your application into more or less discrete subsystems/"services". that way it becomes easier to react to bottlenecks in the subsystems instead of having to operate on the whole system.

ideally you design your system like that in the beginning but usually you grow and find out the harder way... step by step.

still there are a couple of things that are "always (about) the same": for example do session mangagement or logging/sitestats usually put quite a bit more write load (INS/UPD/DEL) on a system than other parts of a system.

so if your product grows the write stress these subsystems/functionalities put on a system on the one hand and the read load from other subsystems on the other hand make it hard to optimize your db/storage systems because they have quite contrary I/O needs.

if you have separate subsystems that run as discrete services with their own API it becomes much easier to put out a fire that breaks out due to growth or load spikes.

so to add to the comment by moe: "you scale applications" - and you get into a better position to do so if you design your applications in a way that they are composed of seperate subsystems that communicate via apis.