FeatureHub Architecture

Overview

FeatureHub architecture is primarily focused on being highly scalable and resilient cloud-native platform, that can deliver feature flags updates securely in near-realtime. Two types of feature flags updates are supported - Streaming (via SSE) and REST (GET). You can choose which one is suitable for you, based on your application type and requirements.

The way that FeatureHub is architected is designed for various different implementation sizes and scales. Fundamentally there is a separation of concerns of all the main components, so they can be scaled independently and when needed. All components are Docker images and are intended to be used with that technology (i.e. Docker/OCI or Kubernetes). You can find documentation for the main deployment options of FeatureHub in the installation section.

High level architecture example

Architecture
Communication between Edge and Dacha(Cache) is shown via REST on this image, which can be configured optionally. By default, it is via NATS.

This example shows Streaming + REST feature updates deployment which is designed to scale to millions, even billions of requests. Since version 1.5.9 we recommend to use "Dacha2" Lazy Cache system.

Platform Components

The Management Repository - MR (FeatureHub Server)

This is the main admin server and is the source of truth for the FeatureHub application. All users login here (via local, OAuth2 or SAML), all portfolios, applications, environments, groups, features, etc. are all controlled via this. This is always bundled with an Admin UI and backend server and is configured to talk to some external database.

If MR server goes down, it won’t affect the operation of end-user clients, all their data is in the cache (or in the database if you use party-server-ish or edge-rest).

NATS

NATS is the Cloud Native Open Source messaging platform that is very fast and is very adept at scaling to huge volume in a hugely distributed fashion. We use it for FeatureHub to transfer messages about environments, features and service accounts to feed Dacha and Edge.

Dacha

Dacha is where the data that is required by every SDK is cached, and you need at least one of these for an operational FeatureHub system. It can be run in-process (using the Party Server design), or separately. Edge always talks to Dacha which holds permissions, environments, features, and pre-calculated etags for appropriate requests.

Architectural Choices for Dacha

There are two choice for Dacha: Dacha1 and Dacha2 (Dacha2 is available from v1.5.9).

  • It must use NATS as it relies on features provided by NATS

  • When it starts, it completely fills its internal cache, either from another NATS or via the MR. This makes it completely isolate your servers from MR, no deliberate "miss" traffic can impact your Management Repository

  • Edge is able to talk to Dacha over NATS

  • Filling its internal cache can take some time with hundreds or thousands of environments, and MR must be available for it to do so, so it can lead to a complicated start for a new k8s cluster or rollout. This can delay it from being healthy, depending on how fast it can fill its cache, which can lead to operational complexity.

Dacha2 supports multiple async layers. It is a lazy cache:

  • it supports multiple async layers (NATS, Google Pub/Sub, AWS Kinesis (beta))

  • it is based on Cloud Events

  • it caches misses as well as hits to ensure consistent misses do not make it to MR

  • it automatically updates itself as new environments, features, and service account changes are broadcast from MR, so a newly created environment will be a "cache hit" by default.

Edge (Streaming+REST)

Edge is intended to be where the communication with the SDKs live. It is intended to be high volume endpoint but retain little data - only who is connected to it and which environment they are listening to for feature updates. Access to Edge is given by a combination of Service Account and Environment IDs (the API Key). That combination is given a permission structure that can be set in MR, and is usually READ permission. For test accounts, a service account can also have the ability to change, lock/unlock features as it may need to while doing end-to-end tests.

Edge does not attempt to retain the active feature list for each Service Account + Environment. It is highly multithreaded and concentrates requests to Dacha.

It is expected that you will normally run at least two Edge services in any kind of systems setup.

Edge (REST only)

Edge-REST provides only GET and PUT (PUT is normally used for updating features for tests) API options. It allows the SDK to poll for updates but not get realtime updates, and will talk directly to the database. It can be deployed on its own or as part of party-server-ish.

Fastly

If you would like to serve features faster globally or would like to cache feature flags on CDN, FeatureHub has affiliated with Fastly - real-time content delivery network. Integration with Fastly can save costs on deployment infrastructure and make the FeatureHub application stack considerably faster around the world.

We can provide you with the environment variables, and the configuration steps necessary to integrate Fastly with FeatureHub. Pulumi configuration, which can be translated easily into Terraform is also available on demand. Please contact us on info@featurehub.io for further information.

Fastly is also used in FeatureHub SaaS platform to ensure your feature updates are delivered as fast as possible across the globe.