Meteor and Redis missing publish events?

I have a meteor application which runs on multiple servers. We have disabled mongo oplog tailing and instead uses Cult of coders Redis for reactivity.

I have an issue where we are sometimes missing some redis publish events. I dont know if it is due to too many Redis events sometimes being sent or what the cause for this problem is.

My first question is: Is there any TOO_FAR_BEHIND setting for Redis? How does meteor handle if there comes a burst of Redis events? Will it eventually start throwing some events?

What I see happens in our code is the following. I create a document in a collection on one of the servers. After the document is created I setup an observeChange for that specific document. Another server polls for any document in this collection and makes some updates to this document. What happens is that sometimes the observeChange on the other server never gets a redis UPDATE event. Below I show some meta-code of the code

Can you see any reason why observeChanges never gets notified for the update event? I can see that this mostly happens during day time when server traffic is higher which makes be believe that some events are thrown away.

// Server 1
  const  Future = Npm.require('fibers/future');
  const waitingForFinish = new Future();
  const id =;
  queryHandle = SomeCol.find({_id: id}).observeChanges({
    changed: function (id, fields) {
      console.log("Update received...")
      // Handle job....
  SomeCol.insert({_id: id, someField: "anything"});
  waitingForFinish.wait(); // <----- This sometimes never fies

  // Server 2
  Meteor.setInterval(function() {
    const docs = SomeCol.find({handled: {$ne: true}}).fetch();
    docs.forEach(x => {
      // Do some stuff with the doc and set handled...
      SomeCol.update({_id: x._id}, {$set: {handled: true}});
  }, 1000);

It sounds like you are using redis as a command queue and not just a cache. Are you sure that the events are actually being sent to Meteor? Many years ago when I tried something like this and the cache was too small, it would drop events under moderate latency, high volume because the cache was full and untransmitted events were dropped. We wound up switching to a queue mechanism with guaranteed delivery.