On May 27, 2014, at 5:39 AM, Riyad Kalla <[email protected]> wrote: > I would probably recommend you go with a smaller master-master > replicated network, one in each major region and then allow a bunch of > slaves around each primary to do master-slave replication.
That conflicts with the OPs requirement that "the customer can update its service configuration at any site”. And I don’t think it’s necessary to limit any of the nodes to being slaves. Yes, replication conflicts are possible, but only in cases where a user changes settings at two different sites at roughly the same time, which would be very unlikely since the sites are geographically dispersed. > I'd also point out that every > single write to every single database having a potential 200x write > multiplier across your mesh network might have unforseen consequences > especially during times of heavy traffic If the documents being written are “service configurations”, I’m guessing they don’t change that often and they’re not terribly big. So the amount of traffic doesn’t sound like a concern. (Also, any document change only gets sent once across any particular arc of the mesh.) As for topology: The most efficient setup in terms of overall bandwidth would be a spanning tree. But for robustness in case any of the nodes or arcs fail, as well as lower latency, you might want to add some redundant connections between otherwise-non-adjacent nodes. —Jens
