What I found really misleading is the section about master-master. Especially this one: > This architecture is too risky for a service company. > All it takes

What I found really misleading is the section about master-master. Especially this one: > This architecture is too risky for a service company. > All it takes is for the master to be down, which will > happen, and clients will start having indexing errors. Actually having a single master has benefits and you should never consider a multi-master setup if you don't need to scale writes. It's way easier to handle that, than to handle split brain and other stuff, especially on inter region connections. Keeping a queue in front of the database, etc pp. As said only if you really need write scalability, you should use a master-master approach. Else your problems could be way worse than just "master" is offline.