Crossroads "Brave" app architecture for scale


@woody @spencercarli @bruce

Edit: Assuming that you scaled using DDP and not GQL/Apollo

Can you guys talk more about the specific architecture you used in the Crossroads “Brave” app to get it to 20k users? If I pinged the wrong people, feel free to ping the right people; much appreciated!

  1. How many droplets/instances on modulus did you use?
  2. Did each droplet represent an identical instance of the app, or did you separate different concerns between each instance (e.g. some instances handle main computation, others handle registration, others handle cron jobs, etc.)
  3. Would you have gone with Galaxy or DigitalOcean? If not, do you expect that Galaxy or DigitalOcean would provide the same kind of capabilities in scaling?
  4. What were the specs of your Compose installment? How big was your replica set, etc.?

I would appreciate any answer or insight here, but I’m sure a blog post solely on scaling architecture would be really, really helpful to not only me but also the others in the community! If you know any links which go over scaling architecture on Meteor apps, please do share! Thanks.


@streemo I’m guessing you’re referring to my post and I think another blog post on this topic is a great idea. I’m currently deep into a project, but I’d love to write that blog post at some point. In the mean time, I’ll try to give you some quick thoughts here:

  1. Modulus, we were running 30 servos during launch week.
  2. Each servo was an identical instance of the app. (made sense for our app, might not make sense for yours)
  3. Definitely would have gone with Galaxy. Ran into issues with modulus in terms of sticky sessions. Galaxy does a much better job with this than Modulus IMO.
  4. I remember we increased the memory, but I forget the exact setup. I’d recommend reaching out to Compose support team. They’re great at answering questions helping out with setting up a custom mongodb instance for your apps needs.

Hope this helps! All the best!


The real question for scaling is how many concurrent users you have. 10,000 signups in a day is awesome and I can imagine you may have even had a few thousand concurrent users depending on the dynamics of your app. I would love to hear more about the details.

An article about my own scaling experiences are here (with a bunch of links at the bottom to other scaling articles):


Hi, actually yes I’m referring to that post. Also, your answer was very helpful. Knowing that you had 30 instances gives me a ballpark, thanks so much. I apologize if that was mentioned in the post…

I would very much look forward to a more detailed blog post when you have the time :slight_smile: To anyone else, reading: please like this comment or woody’s comment if you agree!