How It All Fits Together
Let's inspect how we can combine all of the distributed transaction guarantees.
As we have described often, transactions need to provide some guarantees if applications are to benefit from them.
Distributed transactions need to provide similar guarantees.
Guarantees distributed systems should provide
Some basic guarantees commonly used are contained in the ACID acronym that we analyzed earlier.
Consistency and durability guarantees
Consistency and durability do not require very different treatment in a distributed setting when compared to a centralized, single-node system. For durability, it’s enough for the data to be stored in non-volatile storage before it is acknowledged by the client.
To achieve durability in a distributed system, we should store data in more than one replicas before acknowledging, so that the system can survive the failures of a single node.
To achieve consistency, the system can introduce some additional read and write operations in the transaction’s context to guarantee the preservation of application consistency. These operations may be automatically generated, such as referential integrity constraints from foreign keys or cascades, or they may be defined by the application, e.g., via triggers.
Atomicity and isolation guarantees
The guarantees of atomicity and isolation are more challenging to preserve, and we previously analyzed some of the algorithms we can use for this purpose.
The course examined some algorithms that can help preserve isolation across transactions, and some algorithms that can help preserve atomicity in a distributed system.
Combining algorithms to guarantee all properties
The algorithms must combine to guarantee all properties: atomicity, consistency, isolation, and durability.
Some combinations of these algorithms might be easier to implement in practice because of their common characteristics. For example, two-phase locking has very similar characteristics to two-phase commit, so it’s easier to understand how they can be combined.
Complexity in algorithms
Looking at the previous algorithms presented, it is easy to realize that some of them introduce either brittleness (e.g., two-phase commit) or a lot of additional complexity to a system (e.g., quorum-based commit).
Algorithms that work for both systems
The algorithms presented for isolation can be used in both centralized and distributed systems. However, their use in a distributed system has several additional implications.
For example, two-phase locking requires the use of distributed locks, which is something that is not trivial to implement in a distributed system, as we will explain later in the course.
Optimistic techniques, such as
As a consequence, using transactions in a distributed system comes at a higher cost compared to a centralized system. So, systems that do not have a strong need for distributed systems can be designed to operate safely without them.
That is also one of the reasons why many distributed databases either do not provide full support for ACID transactions or force the user to opt in to use them explicitly.
Get hands-on with 1200+ tech skills courses.