title: What is a good horizontal scaling strategy for a MongoDB change stream reader?
body: <p>I am thinking of implementing a MongoDB change stream reader and I want to make sure I'm doing it correctly. There are plenty of simple examples out there of how to implement the actual reader code, including the <a href="https://docs.mongodb.com/manual/changeStreams/" rel="noreferrer">official documentation</a>, and I'm not too worried about that aspect of it.</p>
  
  <p>I am however a little worried about the reader <em>falling behind</em> the change stream and not being able to catch up and I want to make sure the reader can handle the flow.</p>
  
  <p>The mongo server is a cluster and lets assume for the sake of argument that it is quite busy at all times of day. The change stream API appears to only be compatible with a single instance doing the work given how it must iterate the stream results rather than operate on it like a queue. Therefore I am worried that it is possible that the single instance iterating the results could take longer to do its work than new items are pushed into the stream.</p>
  
  <p>My instinct is to actually have the reader simply read the stream, batch the changes and then push it into a queue where other workers can then horizontally scale to do the work. However I still have a single instance as the reader and its still theoretically possible for it to fall behind the stream, even while only doing the bare minimum work of pushing changes into a queue.</p>
  
  <p>So my questions are, how realistic of a worry is this and is there any way to create the reader in such a way that it can horizontally scale even if it is only streaming the changes into a worker queue? What other considerations should I take into account?</p>