Architecture

Components

A deployment of featuresd comprises the following components:

• the featuresd application server
• a storage repository, which should be durable (one of SQLite, MySQL, PostgreSQL)
• an optional broadcast service using Redis when you are deploying multiple instances of the application server
• an optional cache repository using Redis

The application server

The app server has three logical components:

• HTTP server
• business logic and in-memory cache
• storage repository adapter

Anatomy of a write

When you update a Context using the API, the following actions occur:

1. the request is logged against the current Identity
2. if the change modifies flags:

• flag values are updated in the storage repository in a transaction

3. if the change modifies a prototype:

• a transaction retrieves the current prototype chain from storage and ensures a cycle would not be created
• within the transaction, the new prototype is recorded

4. if any changes were made, cached views of the context and all its descendants are voided
5. a broadcast is sent saying the context was modified; listeners will void their cache

Creating a new context is much simpler, as the prototype chain does not need to be checked for consistency, and no caches need to be voided.

Anatomy of a read

To get a view, we perform the following steps:

1. the request is logged against the current Identity
2. if there is a cached view for the context, return it
3. if not, build a view and cache it

• query the storage for the prototype chain and cache the chain
• query the storage for all values of all contexts in the chain
• build the view by iterating over all contexts in chain order