[0] https://www.gov.uk/government/organisations/government-digit...
[1] https://technology.blog.gov.uk/2016/08/16/scaling-the-petiti...
The reasoning seems spurious, is not that difficult for a db to keep a row count .. and of it were then you could do that out of bounds.
1k updates per minute it's surely not that much traffic for a national site; I wonder what max-load they designed for? If 1M users hit it in a work day then that's 2k users a minute, which seems to be quite a reasonable normal level to design for (there are many petitions, you want to cope with a few being popular on any day; maybe 10k user max load??).
The db is just going to be something like petition index+user index.
Is the reason given just bluster?
I'm not a db person, but are they sharding. Surely as they're only writing simple tuples with a petition they can easily write to multiple separate dbs (shards I guess) and amalgamate the results at leisure?
That link says they need to update the web content perpetually, but it seems it's only the number of signatories they need to keep live, isn't it. So once it breeches 100k then they can estimate the signatory rate (including acceleration) and update the row count when they think 200k will be breeched - at 1k/min updating the row count each hour is fine, presumably. Surely that's not a massive processing job?
I'd love some input here, because naively it seems like they're not handling that much data? A million rows of 1kB is still only 1GB, and they're only gathering a few simple fields in each tuple??