Keep an Azure Table atomic update set inside one partition

Source facts

Microsoft limits an Azure Table entity-group transaction to entities in the same partition. Its data-modification guidance distinguishes that atomic boundary from patterns for eventual consistency across partitions or storage systems. Updating or deleting an entity also requires its PartitionKey and RowKey, so key selection affects both locating the target and grouping the intended changes. Microsoft Learn.

Applicability

Apply this design check to an application using Azure Table storage entity-group transactions. Identify the records that truly must change together rather than assuming that a logical business relationship establishes an atomic storage boundary.

DSE recommendation

Write down the atomic update set before choosing partition keys. Have the application owner list the entities and their actual keys for a representative business operation. If the set crosses partitions, either review a supported same-partition model or explicitly design the separate eventual-consistency workflow and its repair process. Compare that choice with the application’s query and load requirements. Do not label a sequence of independent writes as a single atomic transaction in the runbook.

Verification

In a controlled dataset, verify the partition keys for every proposed transaction participant and exercise the supported update operation. Test the application’s handling of rejected or incomplete workflows through approved failure cases. Confirm that recovery responsibilities are explicit if cross-partition coordination remains necessary. Retain the chosen consistency model with the schema so future key changes trigger a review of the original atomicity assumption.

Official references

Microsoft Learn: Design Azure Table storage for data modification.