Hacker News Reader

Comment by dotancohen | Hacker News Reader

> queue those up in a list (in the code)

That won't work in the language that most server-side website code is written in. PHP processes are created and destroyed per HTTP request, and even the FastCGI implementation won't let one share data across requests. PHP does have a sessions feature, but that data is written to either the filesystem (by default) or a database on every request!

View on HN

Just add Kafka in between

Exactly. When my 10 visitors a day start writing too many comments, I usually jump to containerizing everything, deploying kubernetes, and installing a queuing system w/ workers to handle the load. A zookeeper cluster with Kakfa could definitely work too, and has the added benefit that you can replay history if your SQLite comment database ever got corrupted.

I just don't understand why people can't see the logic behind using something operationally simple like SQLite.

This comment and parent are pretty master level HN trolling.

So you avoid just using a "real" db by adding half a dozen different pieces of software to paper over your "not db" replacement?

It's pretty common to write session data in memory eg. memcache/redis.

Redis is yet another dependency that you can certainly do without.

Yes but if you use SQLite because you value minimalism you would also choose a language that compiles the server to a statically linked binary, e.g. Go, in which case this is a trivial "optimization" to do (if you would even call it that).

I've ran sites in the ~500 users per day category where MySQL and postgre use nearly nothing in resources while user interaction causes complex transactions and competing row-level locks. Sounds pretty minimal to me. Odd though that someone who values golang would want to use DB with a poor reputation for concurrency.

Reply on news.ycombinator.com