Architecture

ConfigDirector Architecture

This section explains the high level architecture on how ConfigDirector evaluates config values and how it delivers updates to client and server SDKs.

For both, client and server SDKs, there are two connection mode options: streaming and polling.

The streaming connection is the default behavior. In this connection mode, the client or server SDK opens a persistent HTTP connection to the ConfigDirector services. Upon connecting, it receives an initial payload with all the config values. From that point on, the server pushes any updates via Server Sent Events (SSE) whenever configs are updated. If the connection is dropped, the SDKs will automatically attempt to reconnect after 2 seconds, and apply an exponential backoff if failures continue.

In the case of the polling connection mode. The SDKs retrieve all the config values with an initial request. From that point on, they periodically poll the ConfigDirector services for additional updates. The polling interval is configurable, but the SDKs enforce a minimum and maximum range. The use of polling is discouraged and should only be used in circumstances where a persistent streaming connection does not work within your system's constraints.

Architecture of client SDKs

Your client or mobile application makes use of one of ConfigDirector's client SDKs to communicate with ConfigDirector's services that evaluate configs.

The high level view is as follows:

1. The ConfigDirector client SDK opens a connection to the ConfigDirector SDK service. It provides the user context, if one was given.
2. The ConfigDirector SDK service evaluates all of the configs' targeting rules using the user context provided, and returns the configs with their evaluated values
3. The client SDK stores the payload it received from the SDK service and returns the appropriate values whenever a config value is requested by the application
4. The client SDK and SDK service keep the connection open. Whenever configs are updated (via the dashboard or admin API) the SDK service pushes events to the client SDK with the updated config values.

If the application updates the user context via the client SDK, the process restarts from step (1) above. A new connection is initiated with the updated user context.

Architecture of server SDKs

Your server application makes use of on of ConfigDirector's server SDKs to communicate with ConfigDirector's services. In the case of server SDKs, evaluation is done by the SDK rather than the remote service.

The high level view is as follows:

1. The ConfigDirector server SDK opens a connection to the ConfigDirector SDK service
2. The SDK service returns all the configs and their targeting rules, without evaluating them
3. The server SDK stores the payload in memory
4. When your application requests a config to be evaluated for a given user context, the server SDK uses the in memory config definitions and targeting rules to evaluate the given config value
5. The server SDK and the SDK service keep the connection open. Whenever configs are updated (via the dashboard or admin API) the SDK service pushes events with the updated configs and targeting rules.