Say I fix a bug in an event listener that populates a query model, and I want to replay the event stream to rebuild that query model. But it's not the only event listener, and the other ones are already correct so I don't want to waste time making them process the replay too.
I can see a few choices:
1. Keep every event listener in its own cluster so I can do a replay on just that cluster. This becomes a maintenance headache if I have a lot of small event listeners, and it's also inefficient to do replays where I *want* multiple listeners to process the event stream since I have to do one replay per listener.
2. A variant of #1: make temporary changes to the cluster configuration to pull out the listener(s) in question just until the replay is complete in production, then put the listener back in the main cluster afterwards such that most of the time there aren't a bunch of clusters. This is tricky in the presence of multiple deployments (dev, QA, production) since you'd have to guarantee that the version with the replay doesn't get skipped in any deployments.
3. Leave all the listeners in one cluster and set a config variable somewhere in the code that they can look at to see if they should ignore or process events during a replay. This seems simplest, though it'll cause a bunch of event listeners to be invoked uselessly.
Any one of those should work, so I'm not stuck, but I'm curious what approaches people have found work best for this kind of thing. In the absence of arguments to the contrary I'll probably go with option 3.
-Steve