The situation is similar to the whole "database inside out" hype that drives application programmers to re-implement proper DBMS.
I am pretty sure the IT hype wheel will turn around and someone will sell 2PC as a new shiny thing.
The situation is similar to the whole "database inside out" hype that drives application programmers to re-implement proper DBMS.
I am pretty sure the IT hype wheel will turn around and someone will sell 2PC as a new shiny thing.
However, if all of the data you need to update is in a single database that supports atomic commits, I'd go with that over sagas.
Scalability depends on lock granularity, what's more...
> Sagas [...] can have high throughput
There is no real difference as sagas in practice implement locking in disguise - take the scenario of flight/hotel/car booking:
Once you book a hotel - this particular resource (a room at a particular time) is effectively locked. Cancelling the booking (because other participants failed in saga) is effectively releasing the lock. The room (resource) is locked for the duration of the whole process anyway (as no other customer can book it during this time).
The downside of sagas is that a programmer is forced to explicitly handle all failure scenarios - which costs development time, is error-prone etc.