Nie wiem czy takie disaster recovery, to powinieneś patrzeć technicznie, czy raczej ze strony biznesowej, tj. istotne jest wznowienie działalności operacyjnej jak najszybciej się da, tak by minimalizować straty wynikające z przestoju biznesu. np. Katastrofa = Pociąg się wykoleił => dany odcinek jest nieprzejezdny i jest masa innych problemów, które wymagają potraktowania z innym priorytetem, np.
- ratowanie rannych
- udrożnienie odcinka
- posprzątanie terenu
Co do problemu z odtwarzaniem wielu komponentów. Na myśl przychodzi mi Restore & Recovery.
- Restore = odtworzenie backupu wszystkich baz do "ostaniego commita"
- Recovery = identyfikacja procesów typu "pending" i ich ponowne wykonanie, ale..
- serwisy powinny oferować tryb "bypass" tak by przetworzenie operacji nie miało konsekwencji biznesowych (bo jak np. zjeść ciastko, które zostało już zjedzone? wysłać paczkę, która została już wysłana itd.),
- lub wspierać idempotentność
Jeśli serwisy nie posiadają odpowiednich operacji wspierających takie recovery, to pozostaje rozwiązanie klasy "data integration" & "data reconciliation".
Dla każdego procesu biznesowego (saga w nomenklaturze serwisów?) można zaprojektować proces kompensacyjny, który dostanie eventa typu "RecoveryNeeded" i ponowi operacje, które zawiodły.
Ogólne rozwiązanie problemu w sposób zautomatyzowany wydaje mi się co najmniej bardzo trudne, bo patrząc tylko technicznie, nie wiadomo jakie będą konsekwencje biznesowe.