Idealine SolutionsDiscuss your product

Part 11 of 16 · Day 2 · Saga, compensation

Failure mid-process with no shared transaction

Problem and experience

A long process without a shared transaction

A mortgage is made up of steps in different services. Each has its own database and no shared transaction exists.

  1. Approvalhotovo
  2. Identityhotovo
  3. Accounthotovo
  4. Disbursementselhala

What now?

  1. Account exists
  2. Money does not
  3. Nobody reverts it

From practiceWhich of your processes takes days and passes through multiple systems?

TakeawayWhen a step in the middle fails, the previous ones are already done and will not revert themselves.

More on this topic

What it means

A distributed transaction across services is impractical in practice. Each step is committed locally and the result may be inconsistent.

Why we use it

We need a mechanism that brings the process back to an acceptable state.

When it makes sense

For long processes spanning multiple services.

Where it breaks

  • Relying on failure “not happening”.
  • Fixing the state by hand only after an incident.

Imagine

The payout fails after the account is opened and the contract signed. The client has an account without money.

Without a shared transaction, we have to maintain consistency at the business level.

Principle, application and exercise

The Process Manager drives the process

A saga is a sequence of local steps. For every step that can be reverted, there is a compensation.

Progress

  1. Process Managerholds the process state
  2. Identity
  3. Account
  4. Contract
  5. Disbursement

Compensation

  1. Payout failed
  2. Close accountAccountClosureRequested
  3. Account closedMortgageAccountClosed
  4. Process: compensated

Trade-offCompensation is not turning back time, just a business countermeasure. Put irreversible steps (payout) last. The Process Manager can turn into a monolith.

TakeawayA saga does not make a process flawless. It makes failure manageable.

In the lab
More on this topic

What it means

The Process Manager listens to events and sends requests for the next step. On failure it triggers compensations in reverse order.

Why we use it

The process has a single place where you can see what state it is in.

When it makes sense

Long-running processes across multiple services, where a partial failure must not leave the system broken.

Where it breaks

  • A compensation that itself fails with no plan.
  • Closing an account that already holds money.
  • A Process Manager that turns into a monolith.

Imagine

The disbursement fails. The saga asks for the account to be closed and the process ends in the “compensated” state. The client is not left with an empty account.

What cannot be undone, we do last.

Training for your team

Would you like this training for your team?

We run the training on your code and your domain problem. We agree the scope, dates and format with you.

Discuss the training