Local server with intermittent Internet connectivity

help
1

I’ve got an interesting issue I’m trying to solve. The app in question is used for stats and live scoreboards for a sports league. In June we’re doing the national championship. This year the venue we’re hosting the event in has poor Internet connection (as in no hardwired Internet at all, so we’re going to have to do our best to grab a connection via cell towers).

I can easily setup a local server and a local network to hardwire all of the scoring apps and all of the scoreboards. But the problem is, that people like to follow the nationals from home (those that didn’t make the trip), so I’d really like to also update our production server as well (which Meteor is on a Linode in Dallas and Mongo is at Compose.io at the same data center).

I’m going to start off trying to use the cell network to run everything off of which if it works then I’m solid. If it fails, then I have to switch to a local server. But I want the local server to batch data out to the public server whenever possible so that those from home can keep close up to date while the people at the live event have no latency. Also some of the stats are more detailed than the scoreboard shows, so even people in attendance might want to hop on their phone to go to the public site to see the more detailed stats.

If it was SQL based, then I would probably use a Master-Master setup. But my understanding of Mongo, this wouldn’t work in the same manner and isn’t really an option for my issue.

Any ideas on an easy way for me to keep a local MongoDB in sync whenever it can communicate with the public MongoDB?

I know I can solve this via code in terms of writing my own sync system that continually polls the public server and when it has a connection can determine the last data it has from the event and then batch out all changes since that time, but I’d prefer to not write that code if I can avoid it.

I’ve actually never tried to see what happens if I had a local Meteor instance connected to a remote MongoDB and then disconnect it from the DB, but I don’t think that would be a viable scenario for the live audience (especially since we need the scoring to be rock solid).

2

I would look at running this as a microservice architecture. The local server (with its local MongoDB) connects over DDP to your master production Meteor server. Updates to the master from the client are sent using Meteor.calls to the appropriate master’s Meteor.methods. Similarly, the master can publish updates for the client to subscribe to (so, that’s your basic simulation of master/master).

Meteor already handles flaky connections over DDP quite well - checkout the docs here and the Meteor Guide here.

This approach is readily scalable for multiple client locations.

1 Like