Multiple meteor + mongo instances in different locations

help
1

Let’s say I want to host 3 instances of my app (Europe, US, Asia) and I want to direct users to the right server based on their location.

In this situation, how do you deal with MongoDB? Mongo’s “primary” and “secondary” architecture doesn’t look like its any use in this situation because all instances need to be able to write to all parts of the database and have that replicated to the other two.

1 Like
2

It’s nuanced.

For the purposes of serving the client code, running regionally-located node servers with the meteor application bundle behind an appropriately-configured load balancer will achieve your goal of “right location.”

With regards to the database, suppose you ran a Mongo replicaset where the primary is in the US, and the secondaries are in US and Asia. Your goal is to reduce the latency of database calls on a regional basis. There are a few notes:

  • Meteor by default connects to mongo with a “PRIMARY” read preference. You can use the the MONGO_URL and MONGO_OPLOG_URL strings to specify read preference of SECONDARY on regional instances using the documentation at https://docs.mongodb.com/manual/reference/connection-string/#urioption.readPreference.
  • Reads will be lower latency, in this sense, and are eventually consistent as long as you use the ordinary DDP-based reactive rendering workflows.
  • By default, writes will not be lower latency—they’ll be higher! I wouldn’t mess with the write concerns (whether or not to wait that a write is confirmed across all database instances), even though you can. The client-side simulation of writes will disguise the latency anyway.

Unless you’re running a realtime game, sharding might be over-optimization for your use case. Overall, Mongo is extremely fast, and using the read preferences (and indices, naturally) correctly will eliminate intercontinental latencies.

Hope this is helpful. The architecture of the client-side isomorphic simulation is really way ahead of its time; just don’t bloat your code too much, since poor client load performance is primarily parsing large amounts of Javascript. Or you can do something something GraphQL, a technology that is obviously inspired by XSLT :wink:

3 Likes