This article talks about organization of data particularly keys and values.

 

Configuration data is stored as key-values. They are a simple and flexible representation of application settings. Keys serve as identifiers to retrieve corresponding values.

Application configuration in a multitenant solution particularly in B2B systems apply to multiple accounts usually several of them that are running on the same system. They are not a secret and not sensitive. They are not applicable to data pertaining to multiple users such as user profiles which can be in hundreds or thousands. These configurations are also edited by multiple teams not just the owning team or its development team but also technical support and other staff members.

A classic example of using a configuration key is to set a default language for an enterprise account. All the users of that account will see this language when they login.

When this configuration data is maintained in a table, then there are rows corresponding to the default language for each of the enterprise account that can be queried with SQL. The configuration store becomes a database in this case. The drawbacks to this approach are that 1) an audit solution needs to be slapped on to the database otherwise direct edits quickly become unmanageable. 2) rollback is more difficult than if it were in files. 3) It is not easy for everyone to see who made the last change 4) It doesn’t support hierarchy for an account such as departments and 5) the table proliferates for as many environments as there are.

The most common approach to storing configuration keys and values is one that facilitates hierarchy. This is best done in folder/file layout while permitting visibility into who changed what along with authenticated access and sharing across all environments. This is best done with a source code control system such as git. When the configuration is checked into the source code such as git. Some best practices continue to apply specifically to configuration key-values.

A best practice involves organizing keys in hierarchical namespaces by using a character delimiter. A convention is not mandated for multiple tenants, but it helps. Keys regardless of their format must be treated. When parsing is avoided, it is easier to not break any usages. Data used within application frameworks might dictate specific naming schemes for key-values. A combined size limit of 10KB usually applies on a key-value. 

Key namespaces must be easier to read with proper use of delimiters to denote hierarchical information. They must also be easier to manage. A key-name hierarchy must represent logical groups of configuration data. They should be easy to query using pattern matching. 

When there is the luxury of using a dedicated configuration service, key-values could optionally have a label attribute. Labels are used to differentiate key-values with the same key. No labels are associated initially, and key-values can be referenced without a label.  A common use of labels is to denote environments for the same key. Labels can also be used to create versions. It is possible to jump forward or fall back between keys using versions. Values depend on content-type with Unicode as the most popular form.  MIME types are also applicable for feature flags, Key Vault references, and JSON key-values. 

Key-values can be soft-deleted which means that they can be recovered. Soft delete will act as a safeguard to scenarios including the case when a deleted app configuration store could be recovered in the retention time-period and the case when an app configuration store is permanently deleted. A soft-deleted store will be retained for a short time known as the retention period. When it elapses, the store is deleted permanently. Key-values can also be purged before the retention period expires. Permission to read and purge deleted stores are granted to owner and contributor roles by default. 

Json content-type is preferable over other formats for key-values because it provides simpler data management, enhanced data export, and native support with app configuration provider. If content is directly edited in file-systems, Yaml might be more terse. When configuration data changes, Event Grid can be used to receive data change notifications. These events can trigger web hooks, Azure functions, Azure storage queues, or any other event handler. Typically, a resource group and a message endpoint are created to subscribe to the topic.