Gestione della coerenza finale durante la persistenza e la pubblicazione di eventi

Attualmente sto lavorando su un'applicazione DDD che utilizza il sourcing di eventi con redis come archivio principale di persistenza. Quindi, sfortunatamente non ho dei rollback incorporati in caso di problemi. L'applicazione è un monolite con 3 radici aggregate separate

Il seguente metodo di servizio

1. Crea il mio aggregrate "Trip"
2. Richiamare il repository del negozio per mantenere tutti gli eventi associati alla creazione dell'aggregato.
3. Richiama il repository dell'istantanea per creare un'istantanea di aggregazione persistente
4. Pubblica eventi per aggiornare altri aggregati nel monolite (mantenere un accoppiamento lento)

Sto usando c # ma la lingua è irrilevante qui:

public async Task<bool> CreateTripAsync(CreateTripRequest request)
{
    //Factory method to create Trip aggregate
    var trip = Trip.Create(request);

    //Persist trip events
    await _tripEventRepository.SaveEventsAsync(trip.Events);

    //Persist trip snapshot
    try
    {
        await _tripSnapshotRepository.SaveAsync(liveTrip);
    }
    catch
    {
        //Deal with eventual consistency by replaying stored events?? How do we trigger this to happen
    }

    //Publish all events associated with creating trip (e.g. 'PassengerAddedEvent') which will affect other aggregates in the same service
    // Mediators publish is fire and forget 
    var tasks = trip.Events.Select(async (ev) => { await _mediator.Publish(ev); });
    await Task.WhenAll(tasks);

    return true;
}

Le mie domande sono:

1. Il mio servizio sta facendo le 4 cose di cui sopra. Tutti loro sono associati alla creazione di un viaggio. Questo violerebbe SRP per questo metodo? Io non la penso così perché sembrano tutti avere lo stesso livello di astrazione.

2. Se la memorizzazione dei miei eventi nell'archivio eventi ha esito positivo, ma improvvisamente lì è un'interruzione dell'infrastruttura e non riesco ad aggiornare la mia istantanea, come posso gestire questa incoerenza? Stavo pensando di pianificare un'attività in background che riproduce gli eventi associati a questo viaggio per ricreare l'aggregato e quando ritorna online lo mantiene. Tuttavia, supponiamo che superi il mio set un numero massimo di tentativi?

3. Dato che sto lavorando in un monolite, sto utilizzando il MediatR pacchetto nuget che è un incendio e dimentico di un pub sub spedizione / gestore dell'evento. Dovrebbe esserci un errore nella pubblicazione di uno di questi gestori di eventi, avrò i miei aggregati in stati incoerenti. So che la maggior parte dei bus di servizio a livello aziendale hanno code di messaggi che vengono automaticamente riprovate / archiviate dopo le eccezioni. Tuttavia non riesco a trovare nulla sull'integrazione di un ESB in un monolite e forse un ESB sarebbe eccessivo nel mio caso ??