ChatSphere's feed is read-heavy. One DB chokes; add replicas and reads fan out while the primary takes writes. Then meet the trade-off: replica lag serving a stale read.
ChatSphere's feed is overwhelmingly reads. Split reads onto replicas and the primary stops drowning — then meet the catch: a replica is always a step behind.
1200 reads/s
+ 80 writes/s · each node handles 500 q/s
🗄️ Primary · reads + writes1280/s · 256%
One node, reads + writes — saturated. Reads are starving writes.
The trade-off: replica lag
Primary (truth)
v1
Replica (read)
v1
The write commits to the primary instantly, but the replica needs a moment to copy it. Read too soon and you see the old value. A feed can tolerate this; a payment balance cannot.
What just happened
▹Most apps are read-heavy. A read/write split sends writes to the primary and reads to replicas — copies of the database — so reads scale by adding replicas.
▹One database serves reads and writes from the same node, so heavy reads starve writes. Splitting them lets each scale independently.
▹The trade-off is replica lag: a replica is a slightly delayed copy. Read your own write from a replica too soon and you'll see stale data — fine for a feed, not for a bank balance.