Replicas
One server for everything
One database server answers every read and every write for Shard Garden. If it fails, the game stops. And reads, like garden pages and leaderboards, far outnumber writes.
Primary and replicas
A replica is a copy of the database, kept up to date from the primary. Google Cloud SQL's docs: "The read replica is an exact copy of the primary instance" and "Read replicas are read-only; you cannot write to them."
Reads can be spread over several replicas. Every write goes to the primary.
Quick check
Where must Remy's server write a player's new save?
- The primary
- Any replica
- The fastest replica
Show the answer
The primary
Replicas are read-only copies. The primary takes every write and sends the changes on to the replicas.
Replication lag
PostgreSQL's docs say streaming replication "is asynchronous by default", so there is "a small delay between committing a transaction in the primary and the changes becoming visible in the standby", typically under a second.
That gap is called replication lag. A player who saves, then reads from a replica, can see the old garden.
Read your own writes
Remy's fix: for a few seconds after a player writes, send that player's reads to the primary. Everyone else keeps reading replicas, where a second-old garden is fine.
Quick check
Right after a save, a read from a replica is sure to show it.
- True
- False
Show the answer
False
Replication is usually asynchronous, so a replica can be a moment behind the primary.
Player message
I planted 3 roses, refreshed, and they were gone. Refreshed again and they were back??
What is the likely cause?
- The first refresh read from a replica that had not caught up yet
- The save was lost and then found
- The roses were planted in another garden
Show the answer
The first refresh read from a replica that had not caught up yet
The save reached the primary at once. One replica lagged for a moment, then caught up.
True story: 43 seconds at GitHub
On 21 October 2018, maintenance work cut GitHub's main US East Coast data centre off from its network for 43 seconds.
In that gap, GitHub's failover tool moved writes to the West Coast databases. But the East Coast had accepted a few seconds of writes that never reached the West. Each side now held writes the other lacked. GitHub chose to "prioritize data integrity over site usability and time to recovery": the site was degraded for 24 hours and 11 minutes, and "no user data was lost".
Source: GitHub: October 21 post-incident analysis (2018), github.blog
Quick check
Why couldn't GitHub simply switch back to the East Coast?
- Each side had writes the other lacked, and switching back could lose some
- The East Coast data centre was destroyed
- Switching back is never possible
Show the answer
Each side had writes the other lacked, and switching back could lose some
Replication lag during a failover can leave two versions of the truth. GitHub took a day to put them back together rather than lose anyone's work.
When the primary fails
If the primary crashes, a replica can be promoted to take its place. PostgreSQL warns that with asynchronous replication, the last transactions may not have reached it, and "the amount of data loss is proportional to the replication delay".
Bolt says: Next: sharding, when one primary is not enough.
Fact-checked 12 October 2026
- Google Cloud SQL: About replication docs.cloud.google.com
- PostgreSQL: High availability and replication postgresql.org
- GitHub: October 21 post-incident analysis (2018) github.blog