> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-cloud-operations/harness_ff_architecture.md).

# Harness Feature Flags Architecture

<figure><img src="/files/rMhOfpnUFmCyPyKF9VrF" alt="Feature Flags logical architecture in a production cluster"><figcaption><p>Click to view full size image</p></figcaption></figure>

This diagram describes the logical architecture of Feature Flags in a production cluster. The architecture includes three microservices:

1. **Admin Service**: The Admin Service is responsible for creation, modification, and management of feature flags. Change events initiated within the Admin Service are transmitted to the Client Service for subsequent processing.
2. **Client Service**: The Client Service serves flag data and evaluates Software Development Kits (SDKs). When flags change, the Client Service sends events to connected SDKs through the Server-Sent Events (SSE) Proxy notification service.
3. **Metrics Service**: The Metrics Service manages, stores, and queries SDK evaluation counts. SDKs send the number of flag evaluations from the last 60 minutes to the Metrics Service. The Metrics Service stores this information as a time series for aggregation and tracking.
4. **SSE Proxy Service**: The SSE Proxy manages long-lived SDK connections. When a flag changes, the Client Service sends event details to the SSE Proxy. The SSE Proxy forwards the event to each connected SDK over SSE.

**Platform features**: Feature Flags uses the Harness Platform. It integrates with Authentication, Authorization, Pipeline, and GitSync capabilities.

Administrative access to flag management is established through the Harness gateway, employing SSL connections to \*.harness.io, ensuring secure and authorized access.

**SDK traffic**: SDKs fetch and evaluate flags. The dedicated Google Cloud Platform load balancer (GCP LB) receives SDK traffic at \*.ff.harness.io. The SSE Proxy service manages SDK stream events. When a flag changes, an event notifies connected SDKs. Requests for flag values route to the Client Service, which returns the flag data.

**Managed services**: Feature Flags uses managed services for scalable data storage and messaging.

1. Flag data is stored in Google Cloud Platform's Cloud SQL.
2. Cloud Memorystore supports events and caching operations.
3. Timescale is used for the storage of historical evaluation data.

<figure><img src="/files/UzyIBfnysvtMUCymJ5Dk" alt="Feature Flags proxy architecture connected to the Harness SaaS Platform"><figcaption><p>Click to view full size image</p></figcaption></figure>

The Feature Flag proxy provides more control and resilience. In this model, one or more proxies connect to the Harness SaaS Platform. The proxy fetches initial flag data and receives flag change events throughout its lifetime.

Customer SDKs connect directly to the proxy to fetch flag rules or evaluation results. During an external network failure, the proxy uses cached data to continue operating and minimize downtime.

**Scalability and redundancy**: Multiple proxy copies can run in read-only mode for redundancy. The read-only proxies are stateless. They rely on Redis to store and persist the latest flag data.

The proxies can be scaled for reads based on the number of SDKs that are connected and volume of flag values being served.