Background
In our development process e believe a lot in microservices and the CICD philosophy. To achieve that we have introduced feature toggles to control the features that are already delivered to the customers. So when the feature is stable enough we enable the feature on the next update and the new features is usable in the product.
With the passage of time and maturity in the product we moved to tenant based solution. The biggest challenge that we faced in that was to toggle functionality based on customer. We had our toggles loaded in the start up of the application. After the start up the objects were registered based on the toggle and the application was started. Now in case of single Tenant installation that was not a problem as we could easily restart the customer to load the latest token. With a multi tenant installation it’s a bit hard to do that as we have to restart all the tenants in order to load the tenants.
So in this post I am going to address this problem and also discuss the solution that we implement. So our old system had the following architecture.
There are my reference classes
So I have a two services service class On and service class Off. The service class On will be called if the toggle is set to ON the service class Off should be called if the toggle is set to OFF
Here is where I am using the toggle and the service so the following steps are performed in this class
- Load the toggle
- Initialize the service collection
- Register based on toggle
- Initialize the service
- Access the Serve method
- Ask user if he wants to continue and if yes continue to step 5
Now when I run this code I will see the following output
Now in this output even if I change the content of the toggles.txt the new toggles will not be effected until I restart the application.
So our solution was to handle it with some changes in the way we load and register the application. so instead of loading the toggle in the beginning we added that part in out interceptor. Before I got into details let me talk a bit about the interceptor.
In the old solution we had toggle information loaded before we access the object. So we already know what type of object it was. In the new solution we will write an interceptor that will be called every time we initialize that service object. Which will give us the opportunity to figure out the toggle before assigning the type of the object lets see the code for better understanding.
So the most important thing to note here is on line 17,18 and 19. We register both the On and off service and then we register the service interface using the Register Capability Components. The register combability is added via extension method to the service collection.
Every time we access the “Serve” method this capability interceptor is called and the toggle is loaded to see load the type of the object. This type if based on the provided toggles. So the toggles are accessed and the type is determined before the method invocation. Lets run the program again to see the output.
As mentioned above the toggles are updated with stopping the application and the latest change was impacted. This is how we solved the multi feature multi-tenant dynamic invocation problem. I know that this could be done in million ways and we could also optimize the code to be more efficient. This code example is just to highlight the problem and a potential solution.
The code is available at