Why Strong Consistency?

One simple approach to this problem that I've used in the past is enabled by noting that you typically only need strong consistency within a single request.

If you can:

• only have a single write master at a time
• separate read-write from read-only database handles (could be enforced by having two sets of db credentials). rw handles must go to your write master, ro handles can go to any of your read replicas.
• have one (at a time) db handle for a request (basic singleton-type approach, typical in connection pool code)
• (nice to have) allow upgrade from ro to rw handle (you have to close the ro handle if so)
• disallow downgrade from rw to ro handle

then you get the nice property that any request which needs a write will thereafter use a read-write handle for all of its subsequent reads as well.

Of course, this puts some of your read traffic onto your write master, but only the reads from reqs which actually update the db. But for our workload (and I think perhaps for many workloads, if you can separate out your metrics etc to a different system) it gives a neat solution which has an easy simplicity to it.