Innanzitutto, la coerenza finale dovrebbe essere abbastanza sicura e tale processo di "gestione dei dati" potrebbe non essere obbligatorio. Potrebbe essere una caratteristica avere diversi stati dei dati nel database. Nel processo di BigData, è piuttosto normale - Google per esempio potrebbe avere diversi stati degli stessi dati nei suoi server.
IMHO la tua domanda potrebbe avere risposte a due livelli, seguendo l'architettura DDD.
1. A livello di infrastruttura
Potresti scrivere del codice specifico per il motore NoSQL che stai utilizzando.
Sarebbe ottimizzato per es. per processi veloci usando KVP, magari con i seguenti schemi:
- Utilizzare memoria come cache il più possibile, per evitare richieste non necessarie sul NoSQL;
- Esegui l'operazione in un processo separato , per ridurre l'impatto sul processo principale;
- Consenti a questo processo separato di utilizzare una mappa / riduci pattern , quindi di iniettare le modifiche come batch;
- Utilizza un qualche tipo di schema CQRS e diversi database: un database KVP per le tue scritture dirette, quindi una lettura secondaria dedicata - solo database, contenenti alcuni dati "lucidati" (anche compilati con map / reduce), pronti per essere utilizzati dai Servizi di dominio .
La tua idea di identificare le chiavi "morte" è interessante. Potrebbe essere implementato all'interno del livello infrastruttura, come parte del processo di archiviazione, ad es. mantenendo una lista in memoria di voci appena scritte, quindi eliminando quindi garbage-collect con un algoritmo di tipo generazionale , che contrassegna le chiavi con un numero di generazione, pronto per rimuovere quello non utilizzato.
2. A livello di dominio
In DDD cerchiamo di essere disgiunti dal database il più possibile . Di conseguenza, eseguire alcuni processi di pulizia dei dati a livello di infrastruttura suona un po 'strano.
Tale pulizia dei dati può essere parte del dominio, in un contesto limitato . Il livello infrastruttura, quando si applica l'algoritmo mappa / riduzione, può utilizzare alcune logiche definite nel dominio, utilizzando oggetti dominio, per convalidare i dati e correggere qualsiasi problema di sincronizzazione.
Ultimo ma non meno importante, se i tuoi dati sembrano incoerenti, potrebbe avere l'odore di un problema di dominio. I tuoi aggregati potrebbero essere definiti in modo errato. Quello che dovresti persistere sono Aggregates Roots , il cui ambito è stato definito da un dato contesto di esecuzione. In genere, gli aggregati vengono mantenuti nel database e garantiscono la coerenza delle modifiche isolando i membri da oggetti esterni (ad esempio, è possibile collegarsi a un aggregato tramite il relativo ID, ma non è possibile accedere direttamente ai relativi oggetti interni). L'eventuale consistenza del KVP dovrebbe essere sufficiente a garantire dati coerenti. Se riscontri problemi di coerenza, potresti decidere di correggere il tuo dominio, che potrebbe avere qualche problema sull'ambito Aggregate Roots .