Ha egy szalon futtatsz valamit, akkor a rendszered valaszideje a feladatok resz idejenk osszegevel egyezik meg, ha pedig parhuzamositod, akkor a leghosszabb futasidovel (leegyszerusitve). Van sok eset, amikor 1) szamit a valaszido 2) vagy mindennek meg kell tortenni vagy semminek. Persze az alkalmazas logikadat is bonyolithatod, hogy hiba turo legyen. Hamar a ket generalis problemajaba utkozol, es implementalhatsz magadnak egy hibaturo protokollt, ami valamifele konszenzussal garantalja azt, hogy a rollback mindenhol meghivodik. Mi tortenik akkor, amikor nem vlaszol a service, ami a rollbacket csinalta? Ahhoz, hogy masik node is atvehesse a kerest idempotensnek kell lennie a muveletnek, nem lehet, hogy elszall az egesz, mert mar nincs meg az adat, amit torolni szeretne. Es addig az alkalmazas all, amig nem lesz elerheto a service es ujra probalja? Vagy timeoutol? De akkor vegkepp nem tudjuk majd, hogy sikerult-e a rollback vagy sem. Akkor kell valami queue, es majd valaki feldolgozza, de varj a queuebol is elosztott meg perzisztens kell. Ok, de hogyan garantaljuk az "exactly once executiont"? Mi tortenik abban az idoben, amig nem sikerul a rollback, hogyan lesz az alkalmazas konzisztens? Csupa csupa olyan kerdes, amire nincs egyszeru valasz. Jah de, beleteszem egy tranzakcioba oket, es amig nincs konszenzus a kommitrol, addig rollback az alapertelmezett muvelet.