[nostrademons]

Most of the time, you can ignore all those concerns when you're starting out. Just run a single-threaded webserver and make one HTTP request = one transaction. You can keep your registered users in memory and store pointers to them in a list as your ACL, and log audit trails as a linked list. Snapshot data to a file periodically for crash resistance, and load it back in at system start.

Sure, you won't be able to run on more than one core, and this won't work if your data exceeds RAM. And I wouldn't do this for anything mission-critical; it's better for the types of free or cheap services where users will tolerate occasional downtime or data loss. But if you never hit the disk and never need to make external connections to databases or the network, you can easily do upwards of 10K req/sec on a single core these days, even in a scripting language like Python. Assume that you've got 10,000 simultaneous actives (this is more than eg. r/thebutton and most websites, and usually translates to around ~1M registered users), this is one req/user/sec, which is pretty generous engagement.

Hacker News is built with an architecture like this. There've been a couple massive fails related to it (like when PG caused a crash-loop by live editing the site's code and corrupting the saved data in the process), but by and large it seems to work pretty well.

[ntoshev]

Yup, I'm actively using this architecture, in Python, with gevent (so that calls to external services don't stall your web server). I spawn long running computations in separate processes. I've described it here:

http://www.underengineering.com/2014/05/22/DIY-NoSql/

It really achieves 10k simple requests/transactions per second on a single core (or a $5/month VPS). The software support for it might have been better though. I should really release some code that helps with things like executing a function in another process, or verifying that some code executes atomically.