This is an interesting one which has recently come up.

There is a microservice which requires some kind of filter in order to manage volume and scale up. Essentially to start with it should only process a subset of things and gradually process more things. In order to decide on what it should process there are some properties on the thing being processed which can be used to filter them in or out of being processed.

The challenge is, where do you put the filter contents. I.e. where do you specify the combination of inclusion properties so that the code does or does not filter the message.

There are two options:

  1. Hard code them in the application
  2. Set application properties which need to be set in the pipeline

The filters will gradually be increased over a period of time until the service is operating over everything. At no point will there be a desire to chop and change them between environments and to scale back or anything in the future. It is just for the transition period.

From people I’ve been speaking to so far there seems to be a lot of favour with option 2 because then it’s possible to just bounce the live boxes without having to run through the pipeline, and then just change the pipeline and redeploy the pipeline in order to make sure the filter isn’t regressed.

I’ve found very few people, from the 2 or 3 that I’ve spoken to, who are in favour of option 1.

Now, I am very much in favour of option 1. It feels wrong to me to have to pollute lots of different places with knowledge about this type of ‘configuration’, if it can be called that. It also feels like there is an extra opportunity for an error or mistake to occur and potentially to have not had the environment fully controlled by the standard release process.

It’s a fascinating one. Personally I’d go for option 1, but I may have to sway to popular opinion just to keep people happy as I can’t seem to provide a sound enough argument as to why option 1 is better than option 2.

For what it’s worth, were this to be used for an AB testing scenario where things are changed frequently then I would probably move it all to the DB and create some kind of nice interface which helps drive that.