It is not possible to apply the ACID properties (atomic, consistent, isolated, and permanent) in distributed systems. Eventual consistency is the new reality. It has functional consequences. The CAP theorem and the shift from ACID to BASE (basic availability, soft state, and eventual consistency) are the foundations for this. The chosen architecture must ensure that the functional requirements for consistency are also met. Cooperation with the business experts during the creation of the new architecture is crucial for success. This is not only a technical issue.

I think if the system expects the user action to be completed only when it is committed in the state machine, it makes sense to trade off latency to ensure consistency across nodes and data. I’m curious if anyone has an approach where we can still optimize the latency without compromising replication strategies 🤔

Quorum based replication may increase system complexity and increase latency. Optimising networks to minimise delays may not ensure consistency between replicas. Distributed systems may have to be developed with optimistic locking and eventual consistency. Eventual consistency is often misunderstood as being risky, but coupled with optimistic locking at entity level, asynchronous/streaming updates and a suitable retry logic, could help achieve the consistency outcomes.

Data replication in distributed systems is a tightrope walk, but solid strategies can make it manageable. I lean on a quorum-based approach for strong consistency, ensuring that a majority of nodes agree before committing changes—this avoids conflicts while keeping data reliable. To tackle latency, I always optimize network routes and ensure data is sharded intelligently to reduce cross-region chatter. Real-time monitoring tools like Grafana help catch any hiccups early, and automated scripts quickly fix minor inconsistencies. It’s all about layering safeguards and continuously optimizing—without these, even a minor replication issue can snowball into something far more disruptive.