Read your own writes

The brief

Ledger keeps a group’s shared expenses. Every page read and every new expense goes through the reads / writes router to one primary database. The database team already runs two read replicas behind a read load balancer, but the router still sends every read to the primary. An evening runs 60 seconds: 400 group pages a second, building from second 20 to 1000 a second (seconds 22 to 47) as groups settle up, then back to 400; 30 expenses a second are added by about 200 active members. Each database has a pool of 10 connections, and a page read holds one for about 15 ms. In this sim, when a database’s pool is used up, the reads that don’t fit fail. The replicas trail the primary: a member who reads a replica soon after adding an expense may not see it. Keep at least 99% served, P99 under 40 ms, and make sure no member ever reads a page that is missing their own new expense. The database tier is the database team’s: you can change the router’s routes and read-your-writes settings, not the databases (the router’s member count, mode and primary are fixed too).

What it checks

1. 1Predict the load on the primary and on each replica when reads are spread across N replicas.
2. 2Choose which reads may go to a replica and which must go to the primary.
3. 3Predict when a read sent to a replica returns stale data, and how the share of stale reads changes as write load and lag grow.
4. 4Choose a routing rule — always primary, primary for a window after a write, or replica once caught up — that gives read-your-writes for the reads that need it while keeping most reads on replicas.

Brush up first

• Read replicas
• Replication lag & read-your-writes

More practice

1. Keep it aliveOpen8 min
2. Launch dayFree with an account20 min