When we designed ConfigCat, our main purpose was to create an architecture that is scalable and resilient to short interruptions, so you don't have to worry about latency, service outages, and unwanted glitches in the system.
Our infrastructure is based on three different cloud providers (Digital Ocean, Microsoft Azure, and Linode) and we run our core services on them. Our traffic manager is in Azure and it uses a performance-based routing method.
We are building our own CDN service to be agile to customer needs and ConfigCat has globally distributed data centers with multiple CDN nodes to guarantee high availability and low response time.
Our Global CDN provides geo-location-based load balancing on server nodes worldwide to ensure the lowest latency. Currently, we have CDN servers set up in Europe (Amsterdam, Frankfurt), in the USA (Newark, New York City, Fremont, San Francisco), and in the Asia-Pacific region (Sydney, Singapore).
If you would like to stay GDPR-compliant, you can change your Data Governance preferences on the Dashboard and opt to use the EU CDN. By switching to EU CDN, your data will not leave the EU.
When a feature flag value is requested by your application, the SDK evaluates feature flag values locally on the client-side and returns them, ensuring that no user data leaves the client application. To achieve client-side evaluation, we apply the same hashing algorithm on the identifier in all the SDKs and give the User Object a specific number on a scale of 0-100.
For instance, a particular user object gets 12 as the hashed number and you set 10% - On in the Dashboard. The targeted user won’t get the feature because 12 is bigger than 10. If you raise the amount to 20%, the user will get the feature because 12 is less than 20. This way we guarantee the stickiness of our percentage rollouts, meaning that if in the above example you decrease the percentage to 10%, again the user will not get the feature. Since all of our SDKs are open source, you can check how this mechanism works.
This is how percentage evaluation looks like in our CommonJS SDK:
Based on the percentage set in the ConfigCat Dashboard, we evaluate the feature on the client-side with the help of this specific number. This way, you can control what type of data (name, key, description, value, targeting rules, and percentage rules) will travel between your apps and ConfigCat CDN servers.
Let’s suppose that for your frontend application, you would like to target users based on sensitive data (e.g., email addresses, names, etc.). In such cases, you can add a layer of protection to that information using a sensitive text comparator. When selecting a condition on the Dashboard, you can choose the IS ONE OF or IS NOT ONE OF sensitive comparators when targeting users to convert the information into a unique hash value.
As the evaluation happens on the client-side, we’ve created over 1,200 SDK unit tests to ensure that all our SDKs are consistent in delivering the same feature flag value to the same users in different clients. As long as you pass the same unique identifier in all the SDKs, the targeted user gets the exact same experience every single time, regardless of the platform used.
If your application can't connect to ConfigCat (e.g., due to internet connection issues), you can continue working with the locally cached value without interruption. This means that ConfigCat SDKs are caching the configurations, so if our CDN server is unreachable, the SDKs will work from the cached configuration. Suppose an SDK couldn't download and cache the configuration at least once. In that case, the getValue calls will return to a fallback value parameter (defaultValue), which is a required parameter in getValue calls. When ConfigCat's CDN is available again, the cached value will get refreshed based on the selected polling mode.
We are open to any type of feedback or feature request. Join our Community Slack and share your thoughts with us about ConfigCat.