Distributed Reliability · Principal
The policy update succeeded. Why did the next read return the old rule?
Take a few minutes to form your approach. Then open a worked answer and compare the decisions.
Reveal a worked answer
Find out where the read went. A write can commit on the primary while an asynchronous read replica has not yet replayed that commit. The next request is routed to the follower and sees the previous policy. No database promise was violated if the application offered eventual follower reads, but the product may have promised that the editor could immediately verify or use the updated rule. PostgreSQL's hot-standby documentation describes the delay before changes become visible on a standby.
For read-after-write behavior, route that session's dependent reads to the primary for a bounded interval or carry a commit-position fence and wait until a chosen replica has replayed at least that position. A fixed sleep is not a consistency guarantee. The replica might catch up quickly under normal load and lag much longer during failover or a heavy query. PostgreSQL's monitoring documentation distinguishes write, flush and replay lag. The relevant moment for a query is replay, when the change is visible there. The exact way to obtain and propagate a safe commit marker depends on the database driver and architecture.
Separate three promises. The editor reading their own write may require a primary or a replay fence. Every user worldwide seeing the new policy at once requires a stronger publication barrier. An agent executing a high-impact action should check the authoritative policy version at the action boundary rather than trusting a convenient follower or stale search copy. If the service cannot reach a sufficiently fresh authority, decide whether to pause the action. A read-only dashboard can often show a clear staleness label instead.
A useful test writes policy version 42, immediately reads through each route, pauses replication, then triggers an agent action. Record which version the agent authorized against. A user updates a document and search answers from the old revision handles a user's document update waiting to reach the search index. This is a narrower database-read problem: primary commit succeeded, but the application read from a follower that had not applied it.
Continue reading
Related questions
Read beyond the question
Explore more distributed reliability
Follow another question in this area, or search the complete Question Library.
Browse this area →Browse Question Library →