FeatureHub Architecture

FeatureHub is available as a bundle (for streaming this is the Party Server, ) or as individual pieces for better scalability and isolation of your Administration side from your applications that require their features.

We go into this in more detail below but suffice to say, the streaming deployment is designed to scale to millions, even billions of requests. Deployed, conceptually it looks like this:

The non-streaming platform (Party-Server-Ish) is designed to scale to less - tens of thousands, possibly more if you have a limited number of environments, or a larger number of read replicas. It is also designed to be much simpler and cheaper to deploy on environments like Google Cloud Run or Azure Container Instances. Deployed, conceptually it looks like this:

The way that FeatureHub is architected is designed for various different implementation sizes and scales, but fundamentally there is a separation of concerns of all the main components, so they can be scaled independently as and when needed.

We discuss the main deployment options of FeatureHub in the installation section and what each part is for.

This is the main admin server and is the source of truth for the application. All users login here, all portfolios, applications, environments, groups, features, etc are all controlled via this. This is always bundled with a 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).

The "Admin" API is defined in an OpenAPI schema and can be generated for a wide variety of platforms. We currently include generated clients for Dart, Typescript, C# and Java, but it is not limited to these.

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

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. In any case, it always communicates via NATS, and when it starts it broadcasts for another complete cache and will fill itself from that. If none is available, it negotiates a master, and will request the MR to provide details. Each Dacha is defined with a name, and the self hosted one is always called "default". All but the very largest of corporations should never need more than one cache name, as it is a form of sharding. Each cache is able to handle thousands of environments and their features.

It is expected you will always run at least two of these in any production environment. They are always listening to the same topic from MR, so they do not suffer split brain.

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. That combination is given a permission structure back in MR, and is usually simply READ. For test accounts, a service account can also have the ability to change features as it may need to while doing end-to-end tests.

It does not currently attempt to retain the active feature list for each Service Account + Environment.

It is expected that you will normally run at least two of these in any kind of environment.

Edge-REST provides only GET and PUT (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.

The SDKs are provided to create an idiomatic method to connection to the server-side event source of feature data from the Edge server. You are welcome to write your own, they are not particularly complicated to write, and we welcome them as contributions!

View documentation and read more about SDK’s here