1What guarantee does read-your-writes provide that basic eventual consistency does not?
Vetora👁️Consistency & Transactions
Read-Your-Writes Consistency
Read-your-writes consistency (also called session consistency) guarantees that after a client performs a write, that same client will always see the result of that write in subsequent reads. It does not guarantee that other clients see the write immediately, making it strictly weaker than linearizability but stronger than basic eventual consistency.
Overview
Read-your-writes consistency addresses one of the most visible problems with eventually consistent systems: a user performs an action (updates their profile, posts a comment, submits an order) and immediately sees the old state when the page refreshes. This happens because the write goes to one replica (the leader or a local coordinator) and the subsequent read is served by a different replica that has not yet received the replication update. From the user's perspective, their action 'disappeared.'
The guarantee is simple: if process P writes a value, any subsequent read by P will return that value or a later one. Other processes may still see stale data -- read-your-writes is a per-client guarantee, not a global one. This makes it strictly weaker than linearizability (which guarantees all clients see the latest write) but significantly stronger than basic eventual consistency (which provides no freshness guarantees at all).
There are several implementation strategies. Sticky sessions route all of a client's requests to the same replica, ensuring reads see the client's own writes (because they are stored locally). This breaks if the replica fails or the client's session migrates. Read-from-leader routes reads to the leader for a short window after a write, then falls back to any replica. Timestamp-based tracking records the client's last write timestamp in their session; reads are directed to a replica that has caught up to at least that timestamp. Logical clock-based tracking uses version vectors or sequence numbers instead of wall-clock timestamps.
Read-your-writes is often combined with monotonic reads (once you have seen value V, you never see an older value) to provide a practical session consistency model that handles the most common user-facing inconsistencies in eventually consistent systems. Together, they ensure that a user's experience is coherent: writes are visible immediately, and the world never 'goes backward' during a browsing session.
Key Points
- 1Read-your-writes is a per-client guarantee: client C always sees its own writes. It says nothing about what other clients see, making it weaker than linearizability.
- 2The guarantee prevents the 'vanishing write' problem: a user updates their profile, refreshes, and sees the old profile. This is the most user-visible artifact of eventual consistency.
- 3Sticky sessions (routing via session affinity to a specific replica) are the simplest implementation but break on replica failure or session migration. The client must handle failover by refreshing from another replica.
- 4Timestamp-based routing records the client's last write timestamp (or LSN -- log sequence number) in their session. The read request includes this timestamp, and the serving replica waits until it has caught up before responding.
- 5In a multi-datacenter setup, read-your-writes may require cross-DC routing for a brief window after a write. Writing to the local DC and reading from the same DC achieves read-your-writes within a single DC, but cross-DC reads may be stale.
- 6Read-your-writes + monotonic reads = practical session consistency. This combination covers the vast majority of user-facing inconsistency complaints without the full cost of linearizability.
Simple Example
Updating Your Social Media Bio
You change your bio from 'Engineer' to 'Senior Engineer' and hit save. The write goes to Replica 1 (the leader). You refresh the page, but the read is served by Replica 2 (which has not received the update yet). You see 'Engineer' -- your change vanished! With read-your-writes, the system ensures your refresh either goes to Replica 1 (which has your write) or waits until Replica 2 catches up. You always see 'Senior Engineer' on refresh. Other users may briefly see 'Engineer' -- that is acceptable because they have no expectation of seeing your update instantly.
Real-World Examples
Facebook (Meta)
Facebook implemented read-your-writes consistency for its TAO (The Associations and Objects) cache layer. After a user writes (e.g., posts a comment), subsequent reads from that user are routed to the same cache server that processed the write, ensuring the user sees their own comment immediately. Cross-region reads fall back to the local cache, which may be stale for a few seconds. This session affinity approach handles billions of read-your-writes guarantees per day.
Amazon DynamoDB
DynamoDB offers strongly consistent reads (routed to the leader partition) that can be used selectively after writes to implement read-your-writes. A common pattern: write an item, then read it back using ConsistentRead=true to confirm the write. Subsequent reads can use eventual consistency (default) once the client no longer needs the recency guarantee. This selective approach minimizes the latency and cost of strong consistency.
Google Firebase / Firestore
Firestore provides read-your-writes consistency by default for all clients using real-time listeners. When a client writes to Firestore, the local cache is updated immediately (optimistic update), and the listener receives the updated value before the write is confirmed by the server. This makes the UI feel instant while the backend asynchronously replicates the write. If the write fails, the listener receives a correction.
Trade-Offs
| Aspect | Description |
|---|---|
| User Experience vs Cost | Read-your-writes dramatically improves user experience (no vanishing writes) at minimal cost. Sticky sessions add no extra reads; timestamp routing adds a small metadata overhead. The cost is much lower than full linearizability while addressing the most visible consistency problem. |
| Sticky Sessions vs Fault Tolerance | Sticky sessions route all reads to one replica, which means a replica failure disrupts the session. The client must re-establish the session on another replica, potentially seeing older data. Timestamp-based approaches are more resilient because any replica can serve the read once it catches up. |
| Single-DC vs Multi-DC Complexity | Within a single data center, read-your-writes is straightforward (read from the leader or the local replica). Across data centers, the user's write may go to DC-A, but their next read may be served by DC-B. Cross-DC read-your-writes requires either routing the read back to DC-A (adding latency) or waiting for DC-B to catch up (adding delay). |
| Scope of the Guarantee | Read-your-writes applies within a session. If the user switches devices (laptop to phone), the session context is lost and they may see stale data. Extending the guarantee across devices requires server-side session tracking keyed by user ID, not session cookie. |
Case Study
Facebook TAO: Session Consistency at Billion-User Scale
Scenario
Facebook's social graph serves trillions of reads per day from a globally distributed TAO cache. Users expect to see their own posts, comments, and reactions immediately after submitting them. With billions of concurrent sessions, full linearizability was impractical -- every read would need to check with the master database, overwhelming the write path.
Solution
TAO implements read-your-writes via cache affinity. After a write, the local TAO cache server is updated synchronously. Subsequent reads from the same user are routed to the same cache server (via consistent hashing of the user's session). If the cache entry is invalidated (by a background replication update), the cache fetches the latest value from the database before responding. Cross-region reads use the local region's TAO cache, which receives asynchronous replication from the primary region.
Outcome
TAO serves 99.9% of reads from cache with sub-millisecond latency while providing read-your-writes consistency for the writing user. The cache hit rate exceeds 99.8%, meaning only 0.2% of reads touch the database. Cross-region replication lag is typically 100-500ms, which is acceptable because other users are not sensitive to sub-second staleness on social graph data. The architecture handles 10 billion+ read-your-writes guarantees per day.
Common Mistakes
- ⚠Confusing read-your-writes with linearizability. Read-your-writes is a per-client guarantee; linearizability is a global guarantee. After client A writes, client B may still see stale data under read-your-writes but not under linearizability.
- ⚠Not accounting for cross-device sessions. If a user writes on their laptop and immediately checks their phone, the phone's session has no context about the laptop's write. The user may see stale data -- this is not a bug in read-your-writes, but it confuses users.
- ⚠Implementing sticky sessions without a fallback. If the sticky replica fails, the client must be able to fall back to another replica. Without fallback logic, sticky sessions reduce availability.
- ⚠Assuming CDN or proxy caches respect read-your-writes. A CDN may serve a cached (stale) page even after the user's write. Implementing read-your-writes requires cache-busting (e.g., adding a version parameter to the URL) or bypassing the CDN for post-write reads.
Related Concepts
See Read-Your-Writes Consistency in action
Explore system design templates that use read-your-writes consistency and run traffic simulations to see how these concepts perform under real load.
Browse TemplatesVerify read-your-writes after posting a message
Metrics to watch
read_your_writes_violationsread_latency_msrouting_accuracy_pctp99_latency_ms
Test Your Understanding
2What happens to read-your-writes consistency when a user switches devices?