...yeah, so this thing has a pretty obvious limitation: because we use simple files to store events, we really don't want more than one thing to try and write to any of them at once. so we don't want to ever run with any kind of threading or anything like it.

My current thinking about this is: that's fine and intended. Just document that this should only ever be deployed that way, and only do that. It's just not intended to get that many requests, period, so it's fine that we intentionally don't try and be any more clever than "deal with one request, synchronously, at a time".

We could try and "fix" this in all sorts of ways, by using some kind of DB backend instead of a file, by doing file locking, by using some sort of worker queue setup for writing to the files, whatever. If we have to, we can try. But until something convinces me it's necessary I think I don't want to.