Strong Consistency vs. Read-after-write Consistency
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
In distributed systems, consistency is a key concern because it directly impacts the reliability and usability of the system. Two commonly discussed consistency models are "Strong Consistency" and "Read-after-write Consistency." Understanding these concepts is crucial for designing systems that meet specific requirements for data accuracy, performance, and user experience.
Consistency Models in Distributed Systems
Consistency in distributed systems is challenging due to the CAP theorem, which states that a distributed data store can provide only two of the three guarantees: Consistency, Availability, or Partition Tolerance. Therefore, developers must choose consistency models that align with their system's requirements and constraints.
Strong Consistency
Strong consistency, often referred to as linearizability, is a guarantee that every read of a piece of data will always return the most recent write. It's as if there is a global clock and operations on all nodes in the distributed system occur in a manner that respects this global order.
Technical Explanation
In systems with strong consistency:
- All nodes see the same sequence of operations: If a value is updated, all subsequent reads on any node will reflect this update.
- Immediate visibility of writes: There is an implicit guarantee that once a write completes, any subsequent read operation will return the latest written value.
- Synchronous replication: Typically, strong consistency models require synchronous data replication, meaning that the write operation is not considered complete until it has been confirmed by all nodes.
Example
An example of a system that emphasizes strong consistency is a relational database like PostgreSQL or MySQL, where ACID properties are critical. If you update a row of data, any query reading that row will reflect the update without experiencing stale reads.
Read-after-write Consistency
Read-after-write consistency is a weaker form of consistency compared to strong consistency, ensuring that once a write completes, subsequent reads will see that write. However, this consistency guarantee applies only to the client that issued the write.
Technical Explanation
In systems with read-after-write consistency:
- Client-based consistency: This model guarantees that the writer of the data will immediately see the result of their write operation.
- No immediate global propagation: Other clients might experience stale data until the changes propagate to all nodes.
- Eventual consistency for other clients: Over time, all nodes will converge to the latest value, given sufficient time without new updates.
Example
Social media platforms often use read-after-write consistency due to its performance benefits. When you update your profile, you immediately see the changes, but other users might not see the latest data until it propagates through the system.
Key Differences and Considerations
Here is a table summarizing the key differences between strong consistency and read-after-write consistency:
| Criterion | Strong Consistency | Read-After-Write Consistency |
| Visibility of Writes | Immediate for all nodes | Immediate for writer only, eventual for others |
| Use Cases | Systems requiring strict data accuracy (e.g., financial systems) | Systems where availability is prioritized (e.g., social media updates) |
| Consistency Guarantee | Global | Per-client basis |
| Replication | Synchronous | Asynchronous |
| Latency | Higher due to waiting for global confirmation | Lower due to localized confirmation |
Considerations for Choosing a Consistency Model
- Latency Requirements: Strong consistency may introduce higher latency because it requires all nodes to acknowledge a write, while read-after-write consistency can offer lower latency by providing immediate feedback to the writer.
- System Type: If the system operations are highly sensitive (e.g., banking or e-commerce transactions), strong consistency is preferred. For social interactions or media platforms, where user experience can tolerate slight delays, read-after-write might be more suitable.
- Conflict Resolution: In strong consistency, the system resolves conflicts by blocking writes until all nodes agree. In read-after-write, conflicts may be resolved by eventually overriding stale reads as data converge.
- Scalability: Systems with strong consistency may have scaling challenges due to the requirement of synchronous operations. In contrast, systems with read-after-write consistency can scale more easily by allowing temporary discrepancies.
Conclusion
Both strong consistency and read-after-write consistency offer unique advantages and trade-offs, and the choice between them should align with the specific demands of your application. Understanding these consistency models is essential for architects and developers alike to build efficient, reliable distributed systems.
Related reading
- Stuck with understanding how to build a scalable system
- Submitting offsets to kafka after storm batch
- Suggested replication type?
- Suitable library/tool for work orchestration / task load balancing in a distributed system
- Subqueries vs joins
- Suggest Cassandra data model for an existing schema
- Switch Master and Slave role in mysql
- Symfony missing bootstrap.php.cache

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.