Hi! I know this will be hard (or maybe impossible) to answer, but maybe someone has experience.
I already have a meteor application, but it’s only used by ~10 concurrent users so it runs perfectly even in the smallest galaxy container. I’m in the process of making a new version. This one will be used by at least 2-300 concurrent users, maybe even more (6-700).
I have a collection with ~50k items and another one with ~500k items. Both collections can grow over time (around +50k/+500k in 6 months). Every item is linked to a user with a userId field. The updates are not super-intensive. There’s a background process that downloads new data from an external API and updates the items when necessary. It runs every few minutes and updates a few hundred items in each run.
The users can see a list of these items (initial items: 40 with an infinite-scrolling to get more) and they can apply filters/sort to the list. Given the bad reputation of subscriptions, I don’t know if I should get the necessary data with a subscription or with method calls.
Right now I’m using easy-peasy which is basically a redux store and populate the store using grapher queries. But I have no clue what would it cost in terms of CPU/containers if 400 users would subscribe to their documents. It would be nice if they could see the updates in real-time but I’m too afraid to use subscriptions Is there a general rule of thumb? What can I expect? I added redis-oplog with the default settings (i.e. without changing app logic).