4 reasons why Unleash’s architecture is pretty unique [2023]

Updated 2023

The Unleash architecture is made up of three parts:

1. Unleash API

The service holding all feature flgs and their configurations. Configurations declare which activation strategies to use and which parameters they should get.

2. Unleash Admin UI

The dashboard is used to manage feature flags, define new strategies, look at metrics, audit logs, etc.

3. Unleash SDK

Used by clients to check if a feature is enabled or disabled. The SDK also collects metrics and sends them to the Unleash API. Activation Strategies are also implemented in the SDK.

Unleash architecture, updated February 2023

 

You’ll notice that we’ve designed the Unleash architecture with performance, resiliency, privacy, and extensibility in mind.

The Unleash Client SDK polls the Unleash API at regular intervals and caches all feature flags locally. The interval is easily configurable from the client-side.

Performance

In order to be fast, the client SDK caches all feature flags and their current configuration in memory. The SDK also implements and evaluates each activation strategy,

This makes it really fast to check if a flag is on or off. Really, it’s just a simple function operating on a local state. It doesn’t need to pull data from the database.

Resilience

If the unleash API becomes unavailable for a short amount of time, the cache in SDK helps minimize the impact. Even though you won’t receive updates while the API is unavailable, the SDK will keep running with the last known state.

The SDK also persists the latest known state to a local file at the instance where the client is running. It will persist a local copy every time the client detects changes from the API.

Privacy

Our architecture guarantees privacy because the flag evaluations happen in the Client SDK running on the client-side. As a a default, the Unleash API does not engage with your user data. This makes us confident to state that we are GDPR compliant.

Extensibility

We ship Unleash with a few typical activation strategies out of the box. However, most companies have different needs and want to segment their users differently. We have an answer to that, don’t worry.

Strategy constraints let you set certain conditions around activating a feature flag. As of Unleash 4.16, strategy constraints are available to all users of Unleash, including our open source users.

You can also collect strategy constraints a bundle called segments, then reuse the segments as often as you like. Read more about strategy constraints, segments, and more in our awesome documentation.

Strategy constraints, segments, and occasionally custom strategies are pretty much the core of Unleash’s architecture. Whether you’d like to target specific customers, regions, or a number of other variables, you’ll find that Unleash is open to fully customize your rollout strategy.

Get to know Unleash better:

GET STARTED TRY OUR DEMO

Share this article