I've got impression this approach is heavily focused towards tiny DBs with small amount of concurrent writes and single digit teams behind the project. For som

I've got impression this approach is heavily focused towards tiny DBs with small amount of concurrent writes and single digit teams behind the project. For something larger, finding out writes to DB fail is not a big deal - apps have logs after all. Another thing captured my attention is DB sizing/fault tolerance 1.keeping average sized DB of 100-300 GB locally, without much buffer pool/vfs cache with higher chances will slowdown the reads and joins. Something bigger like couple of TB should be even harder to do. 2. Syncing multiple concurrent writes can be even longer or on par - guessing here. 3. Both Redis and Postgres (and MySQL) can be (should be) kept behind LB. If node fails, clustering + LB will handle it. LBs of course can be present per location and provide local reads and forwarding writes to remote. Regarding LB, probably simplest would be have different tcp ports for readwrite/readonly types of load. Reads can be split among multiple replicas be needed. I have not used it for anything big, but from my experience small/average load (80k rps to Redis with 3Gbit of bandwidth) LB was not an issue. 500k rps may change the situation of course, not a silver bullet.