Thread by @UdiDahan

Seriously, can we stop with the flight/hotel/rental-car example for transactions and "distributed sagas" already? I mean, if you couldn't get a rental car, would you really want your flight reservation to be cancelled (known as compensation)? Of course not - it's ridiculous.

There are much fewer cases where the business world requires rollbacks/compensation than technical people would like to believe.

In retail/ecommerce - you go to buy something online, it's out of stock, does Amazon rollback your order? Hell no. There's an actual business term for this state, it's called "backordered": businessdictionary.com/definition/bac…

The better approach is to more deeply analyze and model the business domain, find strong boundaries that can interact in more loosely-coupled/event-driven styles.

It's been my experience that *time* is a hugely important business concept that doesn't get modeled explicitly in domain code nearly enough. This like:

If X doesn't happen within 24 hours of Y, take action Z.

If/when these rules are implemented, it's unfortunately done with batch jobs hitting databases rather than in the domain code itself - resulting in a violation of the Single Responsibility Principle.

The better way to implement these scenarios is with a *stateful* object that is able to correlate between the handling of the first trigger/event and subsequent triggers/events or the passage of time (itself best modeled as the same kind of trigger).

This is exactly what we've done with Sagas in NServiceBus:
docs.particular.net/nservicebus/sa…

MassTransit has something similar they call "automatonymous":
masstransit-project.com/MassTransit/ad…

Let me wrap this up:

Avoid orchestrating multiple business-oriented microservices with process-manager-y things. That results in a distributed monolith, and no, those "distributed sagas" you've been hearing about won't help.

If you want to learn more: particular.net/adsd