The issue may be an unintended consequence of us rolling back 13230568 "cleanup query rows" (no that number is not a typo <.< >.>), which will take about half a week to complete. So things will be like this until then at least, unless we find a fix in the meantime.
Protip: Shard your database such that your tables are close to a maximum of 1 million rows. That's roughly one quarter the keyspace you get with a 32-bit unsigned integer, and it gives you the ability to run transactions over an entire shard within a day's time. The best part is that a shard need not live on its own database cluster, but it can in the event that any one particular shard is eating up a shitton of I/O.
Also, monitor and alert on your tables' keyspaces. Once they reach (better: once you've crossed the future projection of) the 1.5 million rows mark, split that shard up into two separate shards.
This is not fucking difficult, and while there are more sophisticated schemes that use 64-bit keys and wind up reserving, like, 42 bits of it for primary keys on tables and the other 22 bits to determine which shard it's on, the naïve approach works just as well.
FA is such fucking clown college sometimes.