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.