Feature Flag - The Key to Safe and Reliable Deployment 🔑

11st's Core Platform Development Team is responsible for the common components and operational toolchain of Vine, a company-wide MSA platform based on Spring Cloud, and also provides the internal developer platform Wheelhouse. In this process, they built a common library to convert REST(HTTP) calls to gRPC-based calls, but unlike the verification environment, Production, where large-scale traffic converges, may require immediate rollback, so a safety mechanism was needed to separate deployment from feature switching.

The solution is to use Feature Flag. A Feature Flag is a mechanism that turns features on and off at runtime based on conditions, allowing feature exposure to be changed without redeploying code. This enables system stability, A/B testing, personalization, and gradual rollout, and in particular allows new features to be exposed to a subset of users or groups first to reduce risk.

The implementation approach is divided into FlagConfiguration, which contains the flag definitions, Flag Router, which reads flag status, and Flag Point, which branches functionality with conditional statements. If flag status is not read from outside the deployed application, redeployment would be required every time, just like a Spring Boot profile, losing the core benefits of Feature Flag: fast switching and reduced unnecessary deployments.

OpenFeature is used as the standard interface. OpenFeature is a vendor-neutral standard designated as a CNCF Sandbox project, and connects to various Flag Management Systems through its SDK and Provider structure. This article explains how to configure the Flag Backend and Flag Evaluation Engine using the open-source Provider flagd.

flagd supports Boolean, String, Number, and JSON types, and provides features such as Context-based Targeting, Pseudo-random assignment, gradual release, and Flag Aggregation. In Kubernetes, flagd can be injected as a sidecar using open-feature-operator, and 11st deployed the flagd Docker image to EKS and integrated it via Ingress so that the same Engine could be referenced across their Hybrid infrastructure of mixed IDC and AWS EKS. The image version used in the example is ghcr.io/openfeature/flagd:v0.6.6.

Flag definitions are written in JSON or YAML, and flagd watches files, Kubernetes Custom Resources, and HTTP/gRPC endpoints to immediately reflect changes. The key fields are state (ENABLED/DISABLED), variants (value mapping), defaultVariant, and targeting, where targeting operates based on a modified JSONLogic conditional expression. For example, you can assign a specific variant only to users whose email ends with @sk.com, or apply a Canary at ratios such as 50/20/30 using the fractional rule.

In the Java SDK, FlagdProvider is connected to OpenFeatureAPI, and evaluation is performed via Client. The evaluation API supports five types: Boolean, String, Integer, Double, and Object, and provides both get[Type]Value(), which returns only the simple value, and get[Type]Details(), which includes the Flag Key, result value, reason, and error code.