I also vote for improving the Oplog implementation!
We are running into some performance issues with the current Oplog implementation at the moment (click here) and are looking for solutions.
We tried redis-oplog in the past but ran into some weird issues with other libraries also using redis (in our case: “bull-queue”) and had to remove it again because of that, because the bull-queue is a must have for us.
Also, since we have a “split setup” for our biggest database changes (2 separate “non meteor” plain node apps called “workers” compared to 4 meteor “main app” docker containers on a separate server) redis-oplog was also a “no go” for us because there was no really nice way to also get oplog updates “from the outside” (our workers) into redis.
We have no experience with oplogtoredis but: the more libraries and “intermediaries” you add to a “chain of things”, which all have to work in harmony and should have a good performance, the worse usually performance will become. so yeah …
At the moment we are really not sure of what is our way forward … also thinking of removing Oplog completely again …