Discover how to manage conflicting updates and maintain data consistency in distributed systems with key strategies for system architects.

In a distributed system ACID most often only works with a Two-Phase-Commit and this is an anti-pattern for microservices. With the rise of NoSQL and microservices the BASE model becomes more relevant.

Last updated on Jul 13, 2024

Dealing with conflicting updates in a distributed system, how can you ensure data consistency?

In a distributed system, managing data consistency across various nodes can be a complex challenge, particularly when dealing with conflicting updates. Ensuring that all components of the system agree on the state of shared data is crucial for maintaining the integrity and reliability of the system. This article will explore strategies to manage conflicting updates and maintain data consistency in distributed architectures.

1 Version Control

When multiple clients interact with a distributed system, version control becomes essential for tracking changes and resolving conflicts. By assigning a unique version number to each update, you can identify which updates are more recent. If a conflict arises, the system can refer to these version numbers to determine which update should take precedence. This can be implemented using a technique called vector clocks, which helps in maintaining the causal relationship between different updates.

Add your perspective

Michel Viana (PwD)

IT Manager Agile Specialist | Cybersecurity | GDPR | Information Technology | Inovation | Digital Transformation | Cybersecurity | Artificial Intelligence
Report contribution
O controle de versão é crucial para gerenciar mudanças e resolver conflitos de dados. Em caso de conflito, o sistema pode usar os números de versão para decidir qual atualização tem prioridade. Isso pode ser feito com uma técnica conhecida como relógios vetoriais, que preserva a relação causal entre atualizações distintas. É recomendável adotar a metodologia DEVSECOPS para automatizar implantações e versionamento de pacotes, facilitando o processo de rollback.

Translated

Like

2 Locking Mechanisms

Locking mechanisms prevent concurrent transactions from interfering with each other. By locking a data item, you ensure that only one transaction can modify it at a time. Two common types of locks are optimistic and pessimistic locking. Optimistic locking allows multiple concurrent transactions but checks for conflicts before committing. Pessimistic locking, on the other hand, prevents other transactions from accessing the data item until the lock is released. Choosing the right locking strategy is critical to balancing system performance and consistency.

Add your perspective

Thilo Hermann

Vice President bei Capgemini
Report contribution
Implementing a pessimistic locking in a distributed system is a tricky task. Be aware that you have to handle all the edge cases. The risk of running in dead locks is also very high.

Like

3 Consensus Protocols

Consensus protocols are fundamental in distributed systems to achieve agreement on a single data value among distributed processes. Paxos and Raft are two well-known consensus algorithms that ensure a consistent and reliable state even in the presence of failures. These protocols work by having a majority of nodes agree on updates before they are committed, which helps in preventing conflicting updates from causing inconsistency.

Add your perspective

Load more contributions

4 Transactional Integrity

To maintain data consistency, it's important to ensure that transactions are atomic, consistent, isolated, and durable (ACID). Atomicity guarantees that all parts of a transaction are completed successfully or not at all. Consistency ensures that a transaction can only bring the system from one valid state to another. Isolation means that concurrent transactions do not affect each other's execution, while durability ensures that once a transaction has been committed, it will remain so, even in the case of a system failure.

Add your perspective

Thilo Hermann

Vice President bei Capgemini
Report contribution
In a distributed system ACID most often only works with a Two-Phase-Commit and this is an anti-pattern for microservices. With the rise of NoSQL and microservices the BASE model becomes more relevant.

Like
Michel Viana (PwD)

IT Manager Agile Specialist | Cybersecurity | GDPR | Information Technology | Inovation | Digital Transformation | Cybersecurity | Artificial Intelligence
Report contribution
A atomicidade assegura que todas as etapas de uma transação sejam completadas com sucesso ou que nenhuma seja realizada. A consistência assegura que uma transação transforme os dados de um estado válido para outro também válido. O isolamento garante que transações executadas simultaneamente não interfiram umas nas outras, e a durabilidade assegura que, uma vez confirmada uma transação, ela será mantida mesmo em caso de falha do sistema. Isso é o que chamamos de "Fato" na análise de dados.

Translated

Like

5 Eventual Consistency

In some distributed systems, strict consistency may not be required, and eventual consistency can be an acceptable compromise. Eventual consistency means that if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. This model allows for better performance and availability in certain scenarios, such as distributed databases and content delivery networks.

Add your perspective

Steffen Jäckel

Digitaler Enthusiast und begeistert über die Technologien von morgen! Let’s grow together and create value!
Report contribution
Eventual consistency is ideal for systems where immediate and concurrent updates are not critical. It can work well in scenarios such as editorial news systems, where new blog posts are posted by the editorial system but not needed to be immediately available in all db replicas. The benefits of this are high-availability, easy scalability etc., if a No-SQL database is chosen, and minor delays in data synchronization are acceptable. If your application requires data to be immediately consistent across all db replicas, you need to consider alternative solutions. Evaluating specific non-functional requirements for your application will help you. Quality scenarios allows you to go one level deeper and make the selection even more granular.

Like

6 Conflict-Free Replicas

Conflict-free replicated data types (CRDTs) are data structures that power a more nuanced approach to managing distributed data. CRDTs can be updated independently and concurrently without coordination between nodes, and they guarantee that these updates can be merged in a way that resolves conflicts deterministically. This ensures that every replica eventually reaches the same state, a property known as strong eventual consistency.

Add your perspective

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?

Add your perspective

Dealing with conflicting updates in a distributed system, how can you ensure data consistency?

1

2

3

4

5

6

7

1 Version Control

2 Locking Mechanisms

3 Consensus Protocols

4 Transactional Integrity

5 Eventual Consistency

6 Conflict-Free Replicas

7 Here’s what else to consider

System Architecture

Rate this article

Thanks for your feedback

More articles on System Architecture

More relevant reading

Dealing with conflicting updates in a distributed system, how can you ensure data consistency?

1

2

3

4

5

6

7

1 Version Control

2 Locking Mechanisms

3 Consensus Protocols

4 Transactional Integrity

5 Eventual Consistency

6 Conflict-Free Replicas

7 Here’s what else to consider

System Architecture

Rate this article

Thanks for your feedback

Explore Other Skills