Potrei essere in grado di fornire un po 'di intuizione (distorta) (che non dovresti prendere per il valore nominale) dal momento che di recente ho avuto il piacere di fare una dimostrazione di concept nell'implementazione di eventi per uno dei miei prodotti aziendali. Prima di questo POC avevamo un sistema "classico" con un RDBMS in fondo che non salvava alcun evento, la prova del concetto era di sostituire l'intero livello di servizio con un'architettura CQRS che utilizzava GetEventStore per eventourcing e Raven come modello di lettura.
Alla fine, non ci sono state grosse modifiche alle prestazioni che i nostri utenti potrebbero individuare (a volte più veloci, a volte più lenti) rispetto alla classica implementazione RDBMS. Perché? Soprattutto perché sul lato della lettura si sta salvando tutto denormalizzato "pronto all'uso" che rende l'interrogazione davvero molto veloce e semplice. Anche la scrittura è stata piuttosto veloce, anche se abbiamo fatto l'ingenuo "leggi tutti gli eventi da un flusso e applicali" - approccio. Ma dal momento che avevamo fatto la dovuta diligenza nella progettazione del dominio, dovevamo solo leggere un singolo flusso e spesso un flusso sufficiente per un singolo aggregato non aveva molti eventi così rispetto all'unione e al raggruppamento e alle cose che abbiamo fatto nel classico RDBMS in questo modo non è stata molto diversa. E se avessimo avuto abbastanza eventi in un flusso, avremmo potuto utilizzare le istantanee per non dover rileggere ogni singolo evento da uno streaming. Ma in genere non è necessario eseguire anticipatamente tali ottimizzazioni: rimarrai sorpreso dalla rapidità con cui possono essere letti e applicati gli eventi.
Alla fine però, questo è stato più lento (ASPETTA! Non ho appena detto che era più veloce prima?) Dannazione, hai visto le mie bugie!: D) visto che siamo andati anche a un'architettura CQRS dove avevamo diversi server che comunicano tramite messaggistica e quindi anche consistenza BASE. Semanticamente rispetto alla classica versione RDBMS questo era più lento poiché per avere una consistenza completa bisognava aspettare fino a quando l'evento non ha raggiunto il livello di lettura. Tuttavia, gli utenti raramente hanno notato questo rallentamento aggiunto - e anche quando lo hanno fatto è stato del tutto accettabile. E in molti casi ci siamo resi conto che gli utenti non avevano alcun uso per un modello di consistenza completa e non avevamo bisogno di aspettare che l'evento attraversasse l'intero sistema. Gli utenti potrebbero continuare a lavorare comunque. Questa è stata una sorta di realizzazione "dura" che ha richiesto molto tempo ai nostri uomini d'affari per accettare, ma è la verità: la coerenza in un sistema distribuito è comunque un mito, non appena mostri qualcuno sullo schermo è molto probabile comunque vecchio e obsoleto.
In base alla mia esperienza, il principale colpo di performance che prendi da eventi non è il salvataggio dei tuoi dati come un flusso di eventi, è piuttosto veloce e se ottieni flussi giganteschi - inizia a scattare istantanee. L'hit principale della tua performance è quello che scegli tu stesso quando devi attendere gli eventi che attraversano l'intero sistema.
In generale, non direi che "performance" è una buona ragione per non utilizzare l'eventourcing.
Purtroppo, alla fine, non abbiamo scelto di andare nella direzione degli eventi nella mia azienda. Anche se questo non è stato a causa delle prestazioni o di una ragione del genere - è stato solo perché avevamo troppe persone che hanno avuto troppo paura di buttare fuori l'RDBMS. : (