Inconsistency Resolution in Distributed Systems: Versioning

Source: Dev.to

Modern distributed databases such as Amazon DynamoDB and Apache Cassandra replicate data across multiple servers to improve scalability, fault tolerance, and availability. However, replication introduces a major challenge: data inconsistency during concurrent updates. To address this problem, distributed systems use a technique called versioning.

Why Versioning Is Needed

In an eventually consistent system, updates do not reach all replicas at the same time due to network delays or partitions.

Consider a system with three replicas:

N = 3
Replicas: s0, s1, s2

Two clients update the same key at the same time:

Client A → put(key1 = 10)
Client B → put(key1 = 20)

Because of network delays, the replicas may temporarily store different values:

s0 = 10
s1 = 20
s2 = 10

Now the system contains conflicting values for the same key—a write conflict.

What Versioning Does

Versioning allows the system to track the history of writes. Each update is assigned a version identifier.

Example:

(key1, value = 10, version = v1)
(key1, value = 20, version = v2)

Instead of immediately overwriting data, the system may temporarily store multiple versions of the same value. This helps the system determine:

• Which write happened earlier
• Whether two writes occurred concurrently

Two Possible Scenarios

1. One Version Is Newer

v1 → value = 10
v2 → value = 20

If the system detects that v2 happened after v1, the newer version replaces the older one:

v2 replaces v1

In this case, no conflict occurs because the system knows the correct order of writes.

2. Concurrent Versions

Sometimes the system cannot determine the order of writes.

v1 → value = 10
v2 → value = 20

These updates are considered concurrent. Instead of choosing one automatically, the database may return both versions:

key1:
  value1 = 10
  value2 = 20

Now the client application must resolve the conflict.

Client Reconciliation

The application decides how to resolve conflicting values. Common strategies include:

1. Last Write Wins

The system selects the value with the latest timestamp.

Latest timestamp → chosen value

2. Merging Values

Values can be combined instead of overwritten. Example in a shopping cart system:

cart1 = {apple}
cart2 = {banana}

Merged result:

cart = {apple, banana}

This approach ensures that no data is lost.

3. Application Logic

Custom business rules can determine the correct value, e.g.:

• Priority‑based updates
• User‑based conflict resolution
• Domain‑specific merge logic

Versioning with Vector Clocks

Some distributed databases use vector clocks to track the history of updates. A vector clock stores a list of node counters representing update history.

Example:

v1 = {s0:1}
v2 = {s1:1}

If two versions have different histories, the system treats them as concurrent updates. Vector clocks help databases automatically detect conflicts without relying solely on timestamps.

Key Takeaways

• Versioning enables detection of conflicting updates.
• It allows temporary storage of multiple versions of data.
• Conflicts are resolved through various reconciliation strategies.

This approach supports eventual consistency while keeping the system highly available and scalable.

Final Thoughts

Versioning is a fundamental technique in distributed systems. It lets modern databases maintain consistency without blocking writes, which is critical for large‑scale operations. By tracking the history of updates and allowing conflict resolution later, versioning ensures that distributed systems remain reliable, flexible, and highly performant.