

Ask HN: SOA/Microservices central config systems? - rishid

I see all the articles and the trend to move to SOA&#x2F;microservices, but I don&#x27;t see anything related to how architectures provide app config and account data to components. To get our company to market, each app has its own config, we have duplicated account data and different formats everywhere. We are starting to design our central config system and was looking to get ideas on how others do this.<p>We are looking at the various database solutions and trying to decide between relational databases or NoSQL ones. Something like Redis seems great and we could make it fit our model and the API is simple (95% of our code is C) but it lacks querying&#x2F;filtering.<p>Do architectures typically have a storage layer component? This seems valid to me for relational database, SQL queries spread all over seems muddy.<p>Some of our main requirements:
- Audit log of config changes
- Simple API from C (REST&#x2F;JSON api is do-able)
- (Fine grain) notification of config changes, i.e. account 4 deposit limit has changed
- Overriding config on a specific server would be cool
- Highly available<p>Configuration data we will be holding:
- account data (very low count, &lt; 50 accounts)
  - ~25 properties per account
  - sub-accounts do exist and need to &quot;link&quot; back to the parent account
- app config (various app specific flags, IP addresses etc..)
======
davismwfl
This isn't a new problem and unless you have a compelling reason to write your
own, I'd look at existing open source alternatives like zookeeper
[https://zookeeper.apache.org/](https://zookeeper.apache.org/) or etcd
[https://github.com/coreos/etcd](https://github.com/coreos/etcd). Each has its
own plus/minuses

We started ours as just a config document stored in the NoSQL db, but found
using a service like etcd or zookeeper is way better. This is especially true
as the number of services increases and the complexity of configuration goes
up.

