I'm creating a system where there are config keys and values. So for example:
config.key = 10
Is an example of a configuration key and a value. These keys can also have overrides based on "dimensions". So for example, if we wanted to apply config.key
to applications with the dimension foo
, the overridden key would essentially be:
config.key.foo = 20
In future we may have multiple dimensions in arbitrary order, so this could be a possibility in future:
config.key.foo.bar = 30
A more concrete example would be if we had a key/toggle called display.pintrest.feed
that has a boolean
value. So the default value would be false
, but you could have overrides like so:
display.pintrest.feed = false
display.pintrest.feed.femaleUser = true
Here femaleUser
is a dimension (so we want to set the value of this config to true
for only female users).
This is essentially what I am trying to do. My question is regarding persistence. What would be the best way to persist this kind of data? This is data that will be queried somewhat frequently but written to less often. The naive solution would be to use MySQL or PostgreSQL and create a table like this:
+----------------------------------+-------+
| Key | Value |
+----------------------------------+-------+
| config.key | 10 |
| config.key.foo | 20 |
| display.pintrest.feed | true |
| display.pintrest.feed.femaleUser | false |
+----------------------------------+-------+
But we lose the type safety of Value
and also have a single point of failure. We also have a lot of redundancy (the base part of the configuration key is repeated each time). So I wondered about perhaps representing it as a graph so that I could write it to a graph database. I was thinking of modeling it like so:
Is this viable or overkill?
I don't mind using a simple key-value store either but it should be fault-tolerant and should be able to be clustered. Also we only really care about eventual consistency (i.e., don't mind it taking time to propagate changes to all the nodes).
So my question is what kind of data store should back this kind of data? Is a simple key-value store enough or should I go for a graph database? My rationale for the latter is simply to mitigate the redundancy from keys but I don't know if that's strong rationale.