Home > Posts Transaction boundaries

Max Heinritz

Transaction boundaries

Transactions are useful for making atomic updates to database state. The term “transaction boundary” refers to the borders of the transaction – where it begins and ends.

Complex business operations may be implemented with one or multiple database transactions. Therefore, a question arises during software design as to where to place transaction boundaries.

Narrow transaction boundaries

To keep a system modular, I find it’s best to limit the scope of transaction boundaries to the narrowest boundary allowed by business requirements. If two pieces of data do not need to be written in a single transaction, they shouldn’t be, especially across domains.

This leaves open the option of pulling out separate microservices for each domain by changing in-memory service calls to gRPC methods, without refactoring transaction boundaries.

Use cases for database transactions with wide boundaries

Certainly, there is a place for transactions that span multiple tables. These are valid use cases:

In all these cases, I prefer that lower-level database operations are only exposed within their own domain. This can be done with:

This will prevent cross-domain transactions across service boundaries.