The documentation already describes it, see here. When doing load tests, see #118, MySQL is the next bottleneck. There're a few sharding strategies for MySQL, such as explicitly considering shards in the application code or using different storage engines, e.g. MySQL Cluster or using a proxy in front of MySQL, e.g. ProxySQL, Vitess or ShardingSphere. However, perhaps a switch to a different database can be considered too, e.g. TiDB or YugabyteDB.

To be sure this is the next bottleneck, I've implemented it in the application code with mod sharding and two separate MySQL instances. The test server had a throughput of ~9k inserts/updates per second for one MySQL instance. With the sharding implementation and two MySQL instances, the throughput was doubled to ~18k inserts/updates per seconds. The test run was made with a script that plays infinite games without delay against itself. To generate enough load to utilize both MySQL servers this was started 200-300 times which yielded about ~15k req/s. The remaining inserts/updates came from background processes (e.g. the referee). During the test run, the application still responded very quickly with ~50-75ms (full internet roundtrip).