Legacy review of Avoiding Transactions in Azure by stevedowling · Pull Request #8490 · Particular/docs.particular.net

stevedowling · 2026-09-08T10:01:12Z

No description provided.

PhilBastian · 2026-09-08T23:02:29Z

 ### Disadvantages

- There can be only a single transactional resource in the entire system. The technique can only be applied if the application fits the limitations of this transactional resource. As some Azure services throttle quite aggressively, sometimes on behavior of other tenants, capacity planning might become an issue.
+- There can be only one transactional resource in the entire system. This technique can only be applied if the application fits within the limitations of this transactional resource. As some Azure services throttle quite aggressively, sometimes due to the behavior of other tenants, capacity planning might become an issue.


Suggested change

- There can be only one transactional resource in the entire system. This technique can only be applied if the application fits within the limitations of this transactional resource. As some Azure services throttle quite aggressively, sometimes due to the behavior of other tenants, capacity planning might become an issue.

- The entire system is limited to only a single transactional resource and, therefore, this technique can only be applied if the application fits within the limitations of this transactional resource. Since some Azure services throttle quite aggressively, sometimes due to the behavior of other tenants, capacity planning may become an issue.

PhilBastian · 2026-09-08T23:04:08Z

+If a resource does not support transactions, atomic operations combined with automatic retries can be used to ensure consistency. The idea is that every atomic operation is *transactional*, meaning that the whole operation either succeeds or fails as a single unit. If all operations conform to that rule, then transactions are not needed anymore.

-One operation that fits this criteria is a unit of work pattern with batching. With some restrictions, it can be used to emulate a transaction. Azure Storage Services allow grouping a number of operations into a single batch in order to make the whole set atomic. However, it works only for Azure Storage Tables and only when the partition key for all operations is the same.
+One operation that fits this criterion is a unit of work pattern with batching. With some restrictions, it can be used to emulate a transaction. Azure Storage Services allow grouping a number of operations into a single batch in order to make the whole set atomic. However, it works only for Azure Storage Tables and only when the partition key for all operations is the same.


Suggested change

One operation that fits this criterion is a unit of work pattern with batching. With some restrictions, it can be used to emulate a transaction. Azure Storage Services allow grouping a number of operations into a single batch in order to make the whole set atomic. However, it works only for Azure Storage Tables and only when the partition key for all operations is the same.

One operation that fits this criterion is a unit of work pattern with batching. With some restrictions, it can be used to emulate a transaction. Azure Storage Services allow grouping a number of operations into a single batch in order to make the whole set atomic. This only works for Azure Storage Tables however, and only when the partition key for all operations is the same.

PhilBastian · 2026-09-08T23:05:25Z

@@ -45,14 +45,14 @@ Another important consideration is that regular transactions also have a *rollba
 ### Disadvantages

 - The application must ensure that operations related to business logic are atomic, i.e. have a single insert, update or delete statement per operation. That often requires changes in program structure.


Suggested change

- The application must ensure that operations related to business logic are atomic, i.e. have a single insert, update or delete statement per operation. That often requires changes in program structure.

- The application must ensure that operations related to business logic are atomic; i.e. have a single insert, update or delete statement per operation. That often requires changes in program structure.

PhilBastian · 2026-09-08T23:06:53Z


 ## Sagas and compensation logic

 Sagas are essentially a stateful set of message handlers that can be used to track and orchestrate a transaction. The handlers communicate with each other, each of them performs a part of the transaction and then notifies whether it succeeded or failed. Depending on the partial results, the saga decides what needs to happen to the rest of the transaction; whether to continue the transaction or to roll it back. The latter is often referred to as *compensation*, as it tries to compensate for the failure at a business logic level.


Suggested change

Sagas are essentially a stateful set of message handlers that can be used to track and orchestrate a transaction. The handlers communicate with each other, each of them performs a part of the transaction and then notifies whether it succeeded or failed. Depending on the partial results, the saga decides what needs to happen to the rest of the transaction; whether to continue the transaction or to roll it back. The latter is often referred to as *compensation*, as it tries to compensate for the failure at a business logic level.

Sagas are essentially a stateful set of message handlers that can be used to track and orchestrate a transaction. The handlers communicate with each other; each of them performs a part of the transaction and then notifies whether it succeeded or failed. Depending on the partial results, the saga decides what needs to happen to the rest of the transaction; whether to continue the transaction or to roll it back. The latter is often referred to as *compensation*, as it tries to compensate for the failure at a business logic level.

PhilBastian · 2026-09-08T23:07:10Z

 Sagas are essentially a stateful set of message handlers that can be used to track and orchestrate a transaction. The handlers communicate with each other, each of them performs a part of the transaction and then notifies whether it succeeded or failed. Depending on the partial results, the saga decides what needs to happen to the rest of the transaction; whether to continue the transaction or to roll it back. The latter is often referred to as *compensation*, as it tries to compensate for the failure at a business logic level.

-In essence, using sagas is implementing a Distributed Transaction Coordinator that operates on business logic level instead of using a two-phase commit protocol.
+In essence, sagas implement a Distributed Transaction Coordinator that operates at a business logic level instead of using a two-phase commit protocol.


Suggested change

In essence, sagas implement a Distributed Transaction Coordinator that operates at a business logic level instead of using a two-phase commit protocol.

In essence, sagas implement a Distributed Transaction Coordinator that operate at a business logic level instead of using a two-phase commit protocol.

PhilBastian · 2026-09-08T23:10:37Z

 ### Entities and messages with version information

-Idempotency can be achieved by adding versioning information to the entities. Typically it is in the form of a timestamp or a version number.
+Idempotency can be achieved by adding versioning information to the entities. Typically, it is in the form of a timestamp or a version number.


this one doesn't sound right to me

Suggested change

Idempotency can be achieved by adding versioning information to the entities. Typically, it is in the form of a timestamp or a version number.

Idempotency can be achieved by adding versioning information to the entities. Typically it is in the form of a timestamp or a version number.

PhilBastian · 2026-09-08T23:11:29Z

 ### Side effect checks

-In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, for example, when `TheFireIsHot` flag is set to true, then there is no need to `TurnOnTheFire`.
+In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, for example, when the `TheFireIsHot` flag is set to true, there is no need to `TurnOnTheFire`.


Suggested change

In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, for example, when the `TheFireIsHot` flag is set to true, there is no need to `TurnOnTheFire`.

In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, e.g. when the `TheFireIsHot` flag is set to true, there is no need to `TurnOnTheFire`.

PhilBastian · 2026-09-08T23:11:49Z

-In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, for example, when `TheFireIsHot` flag is set to true, then there is no need to `TurnOnTheFire`.
+In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, for example, when the `TheFireIsHot` flag is set to true, there is no need to `TurnOnTheFire`.

 Arguably this is a risky approach that can lead to subtle errors. Although it's useful in the real world, it has to be used very carefully, preferably only if no other approach can be used.


Suggested change

Arguably this is a risky approach that can lead to subtle errors. Although it's useful in the real world, it has to be used very carefully, preferably only if no other approach can be used.

Arguably this is a risky approach that can lead to subtle errors. Although it's useful in the real world, it has to be used very carefully; preferably only if no other approach can be used.

PhilBastian · 2026-09-08T23:13:33Z

 ### Accept uncertainty

-In some systems it is possible to accept uncertainty and potential inaccuracies caused by non-idempotent messages. In some cases the data doesn't have to be consistent at all times. In other systems there might be mechanisms that allow for dealing with inconsistencies afterwards.
+In some systems it is possible to accept uncertainty and potential inaccuracies caused by non-idempotent messages. In some cases the data doesn't have to be consistent at all times. In other systems there might be mechanisms that allow for dealing with inconsistencies afterward.


only just found out this is a difference between American and English

PhilBastian · 2026-09-08T23:14:38Z

-In some systems it is possible to accept uncertainty and potential inaccuracies caused by non-idempotent messages. In some cases the data doesn't have to be consistent at all times. In other systems there might be mechanisms that allow for dealing with inconsistencies afterwards.
+In some systems it is possible to accept uncertainty and potential inaccuracies caused by non-idempotent messages. In some cases the data doesn't have to be consistent at all times. In other systems there might be mechanisms that allow for dealing with inconsistencies afterward.

 Although that might seem unacceptable for many programmers, in the end it is a business decision. It's always recommended to talk to business experts and double-check their expectations.


Suggested change

Although that might seem unacceptable for many programmers, in the end it is a business decision. It's always recommended to talk to business experts and double-check their expectations.

This might seem unacceptable for many programmers, but in the end it is a business decision. It's always recommended to talk to business owners/experts and double-check their expectations.

Grammar

e7879e4

stevedowling requested review from PhilBastian and jpalac September 8, 2026 10:01

internalautomation Bot assigned stevedowling Sep 8, 2026

PhilBastian approved these changes Sep 8, 2026

View reviewed changes

Navigation Menu

Uh oh!

Legacy review of Avoiding Transactions in Azure - #8490

Legacy review of Avoiding Transactions in Azure#8490
stevedowling wants to merge 1 commit into
masterfrom
living-without-transactions

stevedowling commented Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

PhilBastian Sep 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	- There can be only one transactional resource in the entire system. This technique can only be applied if the application fits within the limitations of this transactional resource. As some Azure services throttle quite aggressively, sometimes due to the behavior of other tenants, capacity planning might become an issue.
	- The entire system is limited to only a single transactional resource and, therefore, this technique can only be applied if the application fits within the limitations of this transactional resource. Since some Azure services throttle quite aggressively, sometimes due to the behavior of other tenants, capacity planning may become an issue.

	One operation that fits this criterion is a unit of work pattern with batching. With some restrictions, it can be used to emulate a transaction. Azure Storage Services allow grouping a number of operations into a single batch in order to make the whole set atomic. However, it works only for Azure Storage Tables and only when the partition key for all operations is the same.
	One operation that fits this criterion is a unit of work pattern with batching. With some restrictions, it can be used to emulate a transaction. Azure Storage Services allow grouping a number of operations into a single batch in order to make the whole set atomic. This only works for Azure Storage Tables however, and only when the partition key for all operations is the same.

		@@ -45,14 +45,14 @@ Another important consideration is that regular transactions also have a *rollba
		### Disadvantages

		- The application must ensure that operations related to business logic are atomic, i.e. have a single insert, update or delete statement per operation. That often requires changes in program structure.


		## Sagas and compensation logic

		Sagas are essentially a stateful set of message handlers that can be used to track and orchestrate a transaction. The handlers communicate with each other, each of them performs a part of the transaction and then notifies whether it succeeded or failed. Depending on the partial results, the saga decides what needs to happen to the rest of the transaction; whether to continue the transaction or to roll it back. The latter is often referred to as compensation, as it tries to compensate for the failure at a business logic level.

	In essence, sagas implement a Distributed Transaction Coordinator that operates at a business logic level instead of using a two-phase commit protocol.
	In essence, sagas implement a Distributed Transaction Coordinator that operate at a business logic level instead of using a two-phase commit protocol.

	Idempotency can be achieved by adding versioning information to the entities. Typically, it is in the form of a timestamp or a version number.
	Idempotency can be achieved by adding versioning information to the entities. Typically it is in the form of a timestamp or a version number.

	In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, for example, when the `TheFireIsHot` flag is set to true, there is no need to `TurnOnTheFire`.
	In some situations, it is possible to verify if a command has been executed by checking its indirect side effects, e.g. when the `TheFireIsHot` flag is set to true, there is no need to `TurnOnTheFire`.

	Arguably this is a risky approach that can lead to subtle errors. Although it's useful in the real world, it has to be used very carefully, preferably only if no other approach can be used.
	Arguably this is a risky approach that can lead to subtle errors. Although it's useful in the real world, it has to be used very carefully; preferably only if no other approach can be used.

	Although that might seem unacceptable for many programmers, in the end it is a business decision. It's always recommended to talk to business experts and double-check their expectations.
	This might seem unacceptable for many programmers, but in the end it is a business decision. It's always recommended to talk to business owners/experts and double-check their expectations.

Uh oh!

Conversation

stevedowling commented Sep 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants