Turn off a query handler


We have a situation where we are sending a query to a service A to get some data.
However we are doing another service B to replace this one and it will listen the same queris as service A.

What we would like to know is if there is a way to turn off/turn on a query handler, like a feature flag.

For example, we querying service B but if we find a bug on it, ew want to be able to turn it off and use service A without downtime. And after fix the bug, return to service B without downtime as well.

And we would also like to know if it is possible to have this kind of mechanism for event listeners and commands handlers.


Kind regards
Filipe Marques

1 Like

This seems more a deployment/infrastructure problem than a development problem to me.

I think disabling message listeners might not be such a great idea from design point of view. You certainly will run upon a moment in time in which you forget to enable/disable certain listeners/handlers (especially dangerous for event listeners) with all undesired and strange behaviour as a result.

It think it is a safer and more reliable approach to deploy service B and take service A offline. If you discover a bug on service B, you can relatively fast redeploy service A rolling-back to the previous logic. Since you mention it is a query service, I guess no much harm can be done. I assume your services are running as Docker containers making the downtime short when re-activating an older container to replace the new one.

If you really need no downtime at all. A suggestion worth evaluating could be to spin up service B and use an API gateway to route all traffic to service B before you take service A offline. If you discover a bug on service B, redeploy service A again and reroute all traffic to service A again at the API gateway and take the buggy service offline again. It involves a certain risk though… Keep in mind e.g. for query handlers (from the docs):

In case multiple handlers are registered, it is up to the implementation of the Query Bus to decide which handler is actually invoked

Multiple query handlers for the same point-to-point query will very likely result in unpredictable behaviour.