Progettare una struttura gerarchica con molte letture e scritture?

Se si tratta di un sistema con qualsiasi tipo di scala coinvolta (vale a dire più utenti), quasi sicuramente avrai bisogno di un database. Dovresti averne solo bisogno. I database sono già progettati per gestire la concorrenza.

Il caching entrerà in gioco se, e quando, diventerai il prossimo Netflix. In altre parole, YAGNI (non ne avrai bisogno, almeno non ancora). La memorizzazione nella cache è pensata per essere imbullonata su un sistema esistente, quindi, se il software è architettato in modo ragionevole, dovresti essere in grado di aggiungerlo in seguito.

È CQRS "Segregazione di responsabilità della query dei comandi?" Se scegli un'architettura ragionevole come MVC, dovresti ottenere questo tipo di best practice gratuitamente.

Farei la cosa più semplice che possa funzionare, che (per me) sarebbe mantenere tutto in un database. Probabilmente conserverei il supporto al di fuori del database, solo per ridurre il carico sul pool di connessioni (il trasferimento di diversi GB di dati può legare una connessione DB per un lungo periodo di tempo), ma a parte questo basta mantenerlo semplice. Scrivi ogni modifica alla configurazione nel database, rileggi la configurazione ogni volta che l'interfaccia utente deve essere aggiornata, ottieni tutte le funzionalità funzionanti e poi la profili per ottenere alcuni numeri. Potresti scoprire che è "abbastanza veloce" così com'è, quindi non devi cambiare nulla. Se è lento, sarai in grado di quantificare quanto è lento e dove, quindi puoi iniziare ad ottimizzare le parti che contano davvero a differenza delle cose che sospetti contano. È inoltre utile disporre di un'implementazione di base su cui eseguire il test, in modo da verificare che i miglioramenti delle prestazioni non abbiano infranto nulla.