One thing that I've seen come up from time to time in my career is how to store product configuration data. This "product" data can drive various things: A/B tests we want to run, storing actual facts about our site, or about which SKU has which meaning and set of entitlements.

Often, as an engineer (specifically a web engineer), it's easy to jump to what we know: Create a read-write store with some normalized tables, and build a web UI to go infront of that.

The Web UI Case

Let's think about that for a second. If you're doing this at an enterprise level, there's a solid chance your requirements aren't straight forward, and even if they are, there's a solid chance they'll change in the future. So, let's pick an A/B test example. At first, you may want to only track this as a mod on a session id.

Hypothetically, the work would probably break down like this:

1. Come up with and propose a schema
2. Get the database / resources, launch the schema
3. Create a microservice / macroservice to expose an API which is some contract based on the data in the database
4. Create a web UI, worry about authentication, auditing, get UX design feedback, and some iteration to make sure your non-engineering friends can use it.
5. Validation and promotion management. How does your data go to prod? Does it start in prod right away? Are you leaving yourself open to mistakes?

... But then we get the requirement changes, and now we have a list of users, or to segment by country/tld/cohort/etc. If we have a database, each one of these changes is met with a new table or schema change, along with whatever UI work has to be done to expose this.

Now you're looking at least several weeks of work, or in the worst-case, you might be going into your 2nd month.

The case for git

Now, let's look at git (or specifically a popular git provider, eg. gitlab, github, bitbucket, etc) and the features it provides:

1. Engineer-readible format for storage (assuming json, yaml, etc...)
2. A web UI to view and share the configuration
3. Authorization, review-process, and complete audit and history built in
4. Automation (Many popular providers have CI/CD these days, which you can tie in to launch something on merge)
   1. Validation! If you're automating anyway, validate!
   2. Rolling back is as easy as a reverse merge

Basically what I'm saying is this: Git provides every key function for storing configuration EXCEPT that your non-engineering friends probably can't use it.

.. But then again, you probably could build something on top of git that they could use.

You will still likely have to build something to serve this configuration (Library wrapper, microservice with API). But you would've had to do that with the other option anyway, right?

When Should I Build it Out?

As you can imagine, there's always exceptions. The two that come to mind:

1. When your scale grows beyond what you feel comfortable storing and organizing within a hierarchical git repo. But luckily you probably have a strong contract that won't be too hard to move over if you started by using git.
2. When there is a core requirement that it MUST be changeable by non-technical people.
   1. Even if that is a core requirement, challenge it! There's a solid chance that as a MVP that it isn't actually a requirement

Conclusion

The morale of this story is simple: There can be some great technologies that can already do what you're looking for that are in plain sight!