A wild Mr Huffam appears! He offers 20+ options, with requirements to decide if they are enabled or not. A few of them have a lot of requirements.
And you can’t really cache this, because every time someone hits it, something could have changed. In fact it’s a good bet it has.
Sure, 20-odd things multiplied by another 20 things a few times isn’t going to trouble a computer. Unless lots of users try it all at the same time, on the same poor database server, where the ‘prime directive’ (I am somewhat simplifying relational transaction integrity here) is "make sure nothing goes wrong at all costs".
Just the read locks to determine if {randomplayer} has all the companions can be a bitch. Now add a whole load of write locks too because people are changing things…
There does seem to be a lot of overhead with tons of options; I know the short story editing page takes foreeever to load.
Whatever the problem was, they seemed able to fix it in 10-15 minutes of downtime. You can’t fix too much traffic with maintenance, at least not 15 minute maintenance, so I suspect it was something else.
I believe Fallen London is hosted on AWS, so theoretically I believe they could simply provision a much bigger one-off instance. Depending on how easy it is to deploy a new FL server, it’s plausible that they could fix "too much traffic" within a couple of minutes - at a cost, of course (although AWS’s prices are very reasonable - the most powerful, I/O optimised server, i3.16xlarge, costs under $5/hour - so accounting for a spike lasting a couple of hours would be very unlikely to cost more than $20 or so). In fact, I’d venture that it’s not unlikely that this is exactly what happened.
EDIT: On second thought, unless the Fallen London backend is horribly designed, it really shouldn’t require downtime to just spin up an extra instance, so you’re probably right after all that that isn’t what they did. edited by Dudebro Pyro on 11/8/2017