
UK Gov Petitions site crashes after 600k back call to revoke article 50 - camtarn
https://www.theguardian.com/politics/2019/mar/21/petitions-site-crashes-after-thousands-back-call-to-revoke-article-50
======
stedaniels
Andrew White at the GDS[0] wrote about "Scaling the Petitions service
following the EU Referendum"[1] back in August 2016. I wonder if we'll have
another write up after this petition?

[0] [https://www.gov.uk/government/organisations/government-
digit...](https://www.gov.uk/government/organisations/government-digital-
service)

[1] [https://technology.blog.gov.uk/2016/08/16/scaling-the-
petiti...](https://technology.blog.gov.uk/2016/08/16/scaling-the-petitions-
service-following-the-eu-referendum/)

~~~
pbhjpbhj
>The following morning, White conceded defeat and explained the technical
error that had led to the failure. “Well done everyone – the site crashed
because calculating the trending count became too much of a load on the
database.” //

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?

~~~
pbhjpbhj
More info at [https://technology.blog.gov.uk/2016/08/16/scaling-the-
petiti...](https://technology.blog.gov.uk/2016/08/16/scaling-the-petitions-
service-following-the-eu-referendum/).

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??

