Ways to leverage flux API for database-centric helm-release orchestration?

[preston-willis]

Hello,
Im managing a multi-cluster environment with 3 levels of multi-tenancy with flux. Currently, I'm leveraging kustomize to orchestrate my helm-release heirarchy, but managing my clients has become a bit clunky when it comes to adding/removing levels of the heirarchy and editing configurations. Additionally, I want to build an API around this functionality for an internal management tool.

Heres an example of my heirarchy:

Global configs
    State configs
        County configs
            Client-specific configs 
                helm release (all configs plugged in as helm values)

Using kustomize patches in my repo works great for code deduplication, but managing all of these files is a lot of overhead, and I'd like to abstract out a lot of the complexity.

So I've been thinking about ways to use a database as my source of truth. I know this approach somewhat undermines the flux ecosystem, so just bear with me.

Ideally I would have a listener set up that syncs to the DB and builds my kustomize files to deploy my helm-releases with the correct inherited configurations via the flux API. All of the patches will be committed to my repo (functioning as an audit trail). This way, I can build an API to change configurations, add and remove clients, toggle feature switches, etc.

I know this must be an atypical approach! But I really need a better way to do things...

My questions:
Is there an existing tool for this purpose?
If not, what other tech should I leverage?

What are the pros/cons of this setup?
What other approaches should I consider?

Thanks in advance!