Hi All,
I want my meteor application to be available worldwide with optimal performance. For that I need to host in a few data centers across the world to minimize latency (just some example of latency based on your region - http://azurespeedtest.azurewebsites.net/) and improve bandwidth.
So to scale across multiple data centers you have 1 or 2 load balancers in each data center which routers to your meteor cluster in the same data center. For pointing the user to the correct geo based loadbalancer I was thinking about using amazons route53 for dns lookup based on the least latency. The problem comes in with mongodb. Ideally you want your meteor application and the db in the same data center. You can geo locate one of your replica sets at each data center (mongodb geo distributed replica set) and if meteor uses that mongodb instance for the read operation it will optimize read access. But how or will it be possible to configure it like that (maybe some dns routeing on the mongo url)? Write operations can only go to the master replica set and then there will be a delay again for when the data is available for read at other data centers again. How would you optimize this scenario?
It will be nice if it was possible to have multiple replica sets, each in a different data center next to your meteor cluster, and they are all replicated with each other. I got confused just writing that sentence so I need some help 
Anyone with some ideas and/or experience with this? Maybe its not necessary at all and i am just over (or under) thinking it, how does meteor behave with mongodb not in the same data center?
Thank you.
Riaan
1 Like
It looks like the easiest solution at the moment is just to host your mongo replicate set in the same data center as all your meteor instances and use a CDN for static content. This is not ideal because if I sit in South Africa and my data center is in USA every DDP call will have an extra few milliseconds (100-200+) added to the roundtrip.
The other way will be to use mognodb sharding but livequery does not yet support this so you will have to route DDP connections manually. Read more about this at https://www.meteor.com/livequery
You got the setup right. You can use readPreferrence=nearest and then Meteor instance will try to read from within datacenter.
Note that, by deploying over multiple datacenters you’re exposing your database to the public network. You can setup VPN instead, or compile Mongo with SSL option to keep it safe.
You are right that there will be a delay after writes. I’m having the same setup and I had to write my own implementations for Accounts methods that send emails with tokens (verify email, password…) Depending on which packages you use, you could have similar issues with others. The problem is when you write something into database and then try to read it in the same request - it’s not there because of delay. (if writing to primary and reading from secondary) You can bypass this by reading from primary but then what’s the point of replication?
I suggest, from my own experience with dealing with the same, that you start with a single datacenter, single mongo instance, and keep everything within private network.
You can load balance meteor instances, no issues with that. You can even get an extra SSL support for your app (with HAProxy, for example) and you don’t need to custom-build Mongo with SSL.
If you really want to geo scale, good luck! 
Hi @mpranjic,
Thank you for reply! Did not know about the readPreferrence option and will come in handy.
I think I will stick to the single data center for now and then slowly start scaling outwards.
Thanks again for the suggestions and information!
Regards,
Riaan