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.
No comments:
Post a Comment