upvote
I have a vague recollection that HN also doesn't use a database, it serializes the data structures or something.
reply
It is a typical solution from the 90s, first steps of interactivity after hand-written HTML pages served by Apache. POST request is handled by some Perl script that rewrites the HTML page, then redirects to it or directly sends it as a reply. See the most basic frame-based chats (no Javascript, no nothing).

It only handles massive traffic if reads of those static pages are frequent, and updates are rare. When thousands of users are posting, you have to either block everyone on each write, or subdivide the required synchronisation between boards. Also, the regenerated pages might be used just a couple of times before the next rewrite happens (or not viewed at all, like far away board pages, but you still have rewrite all involved pages as a batch), and not much caching happens. In addition to that, each short comment causes multiple full long pages to be regenerated, and stored on disk. You basically get a very ineffective database with very ineffective primitives.

So usually every image board owner starts with decoupling of message posting and page updates to only regenerate pages once in a while, and process multiple edits at once, then some things stop working, as they assume each state change happens in full in multiple places, then they try to rewrite everything or switch to a real database engine.

reply