3 posts tagged with "reliability"

Outages happen. Even the best engineering teams and the most reliable infrastructure eventually run into network failures, service disruptions, or unexpected connectivity problems.

The real question is not whether a platform will ever experience an incident. It is what happens to your application when it does.

A feature flag service is often part of the path used to manage releases, disable problematic functionality, and respond to production issues. The last thing you want during an incident is for the feature flag system itself to make your application unavailable.

ConfigCat SDKs are designed to avoid that problem. They evaluate feature flags locally, keep using the latest valid configuration when refresh requests fail, and retrieve updates once connectivity returns. Your application does not need to be restarted or redeployed.

Let's look at how this fault-tolerance architecture works.

Local Evaluation: The Foundation of Fault Tolerance​

When you create feature flags and targeting rules in ConfigCat, they are distributed to SDKs through a static configuration file called config.json.

The ConfigCat SDK downloads and caches this configuration, then evaluates flags inside the application process. It does not contact ConfigCat every time your code checks a flag.

This distinction is important. Once the configuration has been downloaded, the SDK can evaluate flags locally using the cached targeting rules and rollout settings. Feature evaluations remain fast, and your application does not depend on a constant connection to ConfigCat for every decision it makes.

The network is only needed when the SDK checks for an updated configuration. If a refresh request fails, the SDK can continue evaluating flags using the version it already has.

This local evaluation model is a central part of the ConfigCat architecture and one of the reasons the SDKs can remain both fast and resilient.

Clients with global customer bases often hesitate to use feature flags for specific use cases due to concerns regarding possible latency and slow response time. Feature flags let you launch new features and change your software configuration without (re)deploying code.

That's why fast response time is of great importance at ConfigCat. For context, ConfigCat is a developer-centric feature flag service with unlimited team size, awesome support, and a reasonable price tag.

To that end, ConfigCat provides data centers at numerous global locations to ensure high availability and fast response time all around the globe. These data centers are all equipped with multiple CDN nodes to guarantee proper redundancy and multiple layers of load balancing based on geolocation to achieve speed, throughput, reliability, and compliance. Thanks to a previous DDoS incident, ConfigCat also got the chance to test its infrastructure in real life and made preemptive security improvements.

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.