Domanda di progettazione: memorizzazione dei dati due volte

Direi store una volta.

Per quanto riguarda i vantaggi che hai elencato sull'archiviazione due volte, non sono sicuro che siano davvero dei benefici. Se mai sono soluzioni per problemi che hanno già soluzioni migliori.

• Essere in grado di ricreare un database: ecco a cosa servono i backup. Se i tuoi schemi divergono mai perché l'API ha bisogno di qualcosa di più rispetto all'app di gestione, le tue possibilità di una ricreazione di successo diminuiscono considerevolmente (e probabilmente si avvicinano a zero).
• Ridurre lo stress sull'API - buona idea, ma probabilmente è meglio risolverlo sfruttando i load balancer, il caching e la scalabilità della maggior parte dei database di documenti. Se queste cose possono scalare abbastanza bene, ridimensionarle quando necessario. Non risolvi un problema che non sei sicuro sia effettivamente un problema.

Gli svantaggi di archiviare due volte, IMO, sembrano piuttosto grandi.

• Affrontare le discrepanze nei dati può essere un enorme problema. Significa molto tempo dedicato allo sviluppatore a capire perché qualcosa che un utente ha appena salvato non funzioni.
• Continuando con discrepanze, quando qualcosa è rotto, quale sistema è giusto? Quali sono i costi della gestione dell'app (e dei suoi report) che sono sbagliati? Che dire se l'API di routing è sbagliata?
• Altre dipendenze esterne per la tua app. Ora devi essere preparato ad affrontare la necessità di avere più database non disponibili. Come gestisci quando uno è giù e un altro è attivo? Salvalo in un posto e aggiusta l'altro in un secondo momento? O semplicemente crash e brucia e spero che il database ritorni presto?
• Tipo di porcellino sul punto precedente, ora hai aggiunto un altro po 'di complessità all'app. Ora avete due database da gestire, uno script esterno o un lavoro che deve essere mantenuto ed eseguito, presumibilmente mantenendo un'altra installazione server / db, ecc.

Memorizza due volte.

L'interfaccia di gestione dovrebbe conservare una cronologia delle modifiche, informazioni di controllo e tutti i metadati extra che non vuoi inquinare il tuo db di routing con