Data Owners, Local Transactions and Consistency Models
Objectives
By the end of the lesson, you can explain what a local transaction guarantees, why it cannot automatically be extended to several data owners, how strong and eventual consistency differ, and what the CAP theorem says.
Why is it needed?
In a monolith, checking stock and saving an order can happen in one transaction. Once the data goes to separate owners (1.3, 3.3), this convenience disappears. Distributed data management is the starting point of all further patterns.
Local transaction and ACID
A database transaction is a group of operations that the database treats as a unit. The classic guarantees are ACID (Atomicity, Consistency, Isolation, Durability): atomicity (either everything happens or nothing), consistency (the rules of the database are not violated), isolation (concurrent transactions do not see each other's half-finished state), durability (a successful result persists). This is a local transaction: valid within the boundary of one database. The statement "the system uses an ACID database" therefore applies to the local transactions of individual databases; it does not extend to the commit of another service or to an external API call.
Data owner and data copy
According to the "database per service" pattern of microservices.io, the persistent data of a service is private, and accessible only through the service's API. This can be implemented as private tables, a private schema or a private database server; the point is the ownership boundary. A shared machine is an operational dependency, a shared table modification is coupling in the data model — the two are separate problems.
The pattern has a price: business transactions spanning several services are hard to implement, queries joining several databases are hard, and several databases have to be operated.
A consumer may keep a local copy for reading, but it must be known where it is refreshed from and how much it may lag. A copy does not receive the right to modify the original. A business document often preserves a historical fact (for example the price at the moment of purchase); the question is whether the copy means the current state or a fact valid at a given moment.
Strong and eventual consistency
Strong consistency may cover several models; the requirement must state what read and ordering guarantee is expected (for example: after a successful write, a read already sees the new state).
Eventual consistency means that if no new write arrives, every read finally returns the latest value. According to the Wikipedia description it is a weak guarantee: it only says that the result will be uniform "eventually", intermediate values may be returned. It does not mean unbounded, untraceable lag, and it does not resolve contradictions by itself. From the user's side it can matter that the modification they have just made does not seem to vanish in a late read view (practice calls this the "read-your-writes" guarantee).
The decision must follow from the business meaning: in a search result, the statement "in stock" can be late, but the actual reservation is decided atomically by the owner of the stock.
The CAP theorem
CAP stands for Consistency, Availability, Partition tolerance. Eric Brewer's conjecture (2000) was proved by Seth Gilbert and Nancy Lynch (2002). According to the theorem, in case of a network partition a distributed system must choose: either it aborts the operation (choosing consistency) or it continues (choosing availability, at the risk of inconsistency); without a partition both can hold. The "pick two out of three" formulation can be misleading, as Brewer himself noted in 2012. According to the PACELC extension (Partition – Availability or Consistency, Else – Latency or Consistency), even without a partition there is a trade-off between latency and consistency.
In practice, what must be decided is not the slogan but the concrete operation: is a modification acceptable over an uncertain connection, and how does the state settle afterwards.
flowchart LR
P["Network partition"] --> C["Abort the operation<br/>(consistency)"]
P --> A["Continue the operation<br/>(availability,<br/>risk of inconsistency)"]
Common misconceptions
| Statement |
Clarification |
| "If the system uses an ACID database, it is atomic." |
Only the local transaction is; not across services. |
| "A shared database server = a shared data owner." |
The server is an operational dependency; the owner is a question of responsibility. |
| "According to CAP, one always chooses two out of three." |
A choice is needed in case of a partition; otherwise both can hold. |
| "Eventual consistency means the data can differ for an arbitrary time." |
It is a weak guarantee, but the lag is bounded by requirements. |
In short
- A local transaction gives ACID guarantees within one database.
- With several data owners there is no automatic shared transaction.
- Strong consistency must be stated as a concrete guarantee; eventual consistency is a weak guarantee that converges over time.
- CAP is about the choice between consistency and availability in case of a partition.
Review questions
- Why does ACID not extend to the database of another service?
- Which data may be late on a product page, and which decision cannot rely on it alone?
- How would you state the CAP choice of a concrete operation?
Learning resources
Data Owners, Local Transactions and Consistency Models
Objectives
By the end of the lesson, you can explain what a local transaction guarantees, why it cannot automatically be extended to several data owners, how strong and eventual consistency differ, and what the CAP theorem says.
Why is it needed?
In a monolith, checking stock and saving an order can happen in one transaction. Once the data goes to separate owners (1.3, 3.3), this convenience disappears. Distributed data management is the starting point of all further patterns.
Local transaction and ACID
A database transaction is a group of operations that the database treats as a unit. The classic guarantees are ACID (Atomicity, Consistency, Isolation, Durability): atomicity (either everything happens or nothing), consistency (the rules of the database are not violated), isolation (concurrent transactions do not see each other's half-finished state), durability (a successful result persists). This is a local transaction: valid within the boundary of one database. The statement "the system uses an ACID database" therefore applies to the local transactions of individual databases; it does not extend to the commit of another service or to an external API call.
Data owner and data copy
According to the "database per service" pattern of microservices.io, the persistent data of a service is private, and accessible only through the service's API. This can be implemented as private tables, a private schema or a private database server; the point is the ownership boundary. A shared machine is an operational dependency, a shared table modification is coupling in the data model — the two are separate problems.
The pattern has a price: business transactions spanning several services are hard to implement, queries joining several databases are hard, and several databases have to be operated.
A consumer may keep a local copy for reading, but it must be known where it is refreshed from and how much it may lag. A copy does not receive the right to modify the original. A business document often preserves a historical fact (for example the price at the moment of purchase); the question is whether the copy means the current state or a fact valid at a given moment.
Strong and eventual consistency
Strong consistency may cover several models; the requirement must state what read and ordering guarantee is expected (for example: after a successful write, a read already sees the new state).
Eventual consistency means that if no new write arrives, every read finally returns the latest value. According to the Wikipedia description it is a weak guarantee: it only says that the result will be uniform "eventually", intermediate values may be returned. It does not mean unbounded, untraceable lag, and it does not resolve contradictions by itself. From the user's side it can matter that the modification they have just made does not seem to vanish in a late read view (practice calls this the "read-your-writes" guarantee).
The decision must follow from the business meaning: in a search result, the statement "in stock" can be late, but the actual reservation is decided atomically by the owner of the stock.
The CAP theorem
CAP stands for Consistency, Availability, Partition tolerance. Eric Brewer's conjecture (2000) was proved by Seth Gilbert and Nancy Lynch (2002). According to the theorem, in case of a network partition a distributed system must choose: either it aborts the operation (choosing consistency) or it continues (choosing availability, at the risk of inconsistency); without a partition both can hold. The "pick two out of three" formulation can be misleading, as Brewer himself noted in 2012. According to the PACELC extension (Partition – Availability or Consistency, Else – Latency or Consistency), even without a partition there is a trade-off between latency and consistency.
In practice, what must be decided is not the slogan but the concrete operation: is a modification acceptable over an uncertain connection, and how does the state settle afterwards.
Common misconceptions
In short
Review questions
Learning resources