Watch & compare
Replication and consistency
Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.
Why we recommend Verify the write
Start with Verify the write: it keeps the acknowledged revision, stale observation and unchanged write count visible together, making the decision not to repeat a successful mutation explicit. The original is the simplest picture of asynchronous copying and stale reads. Read your write adds a useful next step: a wrapper holds a dependent action and releases it after verification, at the cost of a busier five-node diagram.
Original · 26 sec
Original explanation
Replication copies data across nodes, while consistency rules determine what reads can observe.
Read the video sequence
- 0–8s: A replica initially returns v1. The primary commits v2 and acknowledges it while the replica still holds v1.
- 9.5–14.5s: A replica read returns stale v1; reading the primary instead returns v2.
- 17.5–22.5s: Replication applies v2 to the replica, and a later replica read returns the new value.
About this cut
Production: Original prototype; model not recorded.
Recommended · Astra · 30 sec
Verify the write
A stale verification read is not proof that a write failed: check the committed revision through a fresh authoritative read before taking another action.
Read the video sequence
- An agent tool reads a caught-up replica. Version 7 returns and matches the current state; no write has been made.
- One write commits version 8 on the primary. The acknowledgement makes the agent expect version 8, while the replica still holds version 7.
- Verification reads the replica and receives version 7. The tool shows the mismatch and holds further action; it does not repeat the write. Attention shifts to the primary.
- A fresh primary read returns version 8, matching the acknowledged revision. Verification succeeds even though the replica is still behind. This example assumes one writer and no intervening cache.
- Replication later applies version 8 on the replica. The write count remains one. The scene fades to its matching dark endpoint; the illustrated delay is not a latency guarantee.
About this cut
Production: gpt-6-astra.
Illustrative single-writer sequence; timings are not measured replica lag.
Primary verification assumes a fresh post-commit query, no intervening cache, and an available primary.
Application revisions and HOLD policy are proposed tool design, not automatic model or database guarantees.
Does not demonstrate failover, concurrent writers, synchronous replication modes, external deployment completion, or permission enforcement.
Audio was analyzed numerically and visually, not physically listened to.
Self-reviewed; independent comparative ranking and editorial promotion remain separate.
Alternative · Sol · 32 sec
Read your write
Before an agent tool step uses a just-saved plan, check the returned revision and route a stale dependent read to the current primary.
Read the video sequence
- The agent needs plan version 1. A read from the replica returns version 1, the wrapper check passes, and the tool step uses that plan.
- The agent saves plan version 2 on the primary and receives a successful acknowledgement. Its next step now requires version 2, but the replica still has version 1.
- The replica returns version 1 again. The implemented wrapper detects that this is older than the required version 2 and holds the dependent tool step.
- The wrapper retries the read on the current primary. Version 2 passes the check and the tool uses it while the replica still has version 1. This assumes a fresh query after the commit.
- Asynchronous replication catches up and the replica becomes version 2. The animated delay is illustrative, not a promised maximum wait.
- A later tool step waits while a fresh replica read returns version 2. The same check passes and sends the approved version down the green gate to the tool step. The resolved state holds, then fades out for the loop. The check controls plan freshness, not permissions.
About this cut
Production: gpt-6.1-sol.
Revision: gpt-6-astra comparative review.
The version check and primary retry are illustrative wrapper code, not behavior guaranteed by an agent or PostgreSQL; prompts do not enforce freshness or permissions.
Assumes one available current primary, a fresh read snapshot after commit, and no competing writers or caches. A revision check is not authorization or an atomic guard against later changes.
Plan revisions and replication delays are illustrative; elapsed time does not guarantee freshness. WAL transport and replay are abstracted into one copy event.
Audio was analysed, not physically heard. A separate comparative review is saved under reviews/comparisons/replication-and-consistency.json; human editorial promotion remains separate.
These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.
What the review found
- Baseline 5.7–10.6s, Astra 6.2–12.6s, Sol 7.4–13.1s: all show acknowledgement before replica catch-up. Astra retains expected and observed revisions together; Sol retains the saved receipt above the failed check. Baseline replaces its ACK badge with the stale value, requiring more memory from the viewer.
- Astra 12.6–18.4s: HOLD, v7 ≠ v8 and Writes: 1 make the safe response concrete. Verification succeeds while the replica is still v7; baseline 13–14.6s shows the same read-route change without explicitly teaching the no-repeat decision.
- Sol 13.1–19.4s: the downstream tool remains HELD until the primary read passes. Its revised green delivery path makes the release more tangible than Astra’s VERIFIED status, while adding two actors and more eye travel.
- Baseline 17–22.1s, Astra 22–24s, Sol 21.2–28.3s: copying is separate from the earlier successful write. Baseline and Sol confirm recovery with another replica read; Astra ends with the replica applied and the write count still one. Sol’s later step now visibly waits before that final check.
- At 350px, Astra’s 12.6s mismatch and 18.4s equality are the easiest comparisons to read. Baseline has the cleanest topology; Sol’s formerly crowded delivery at 4.5/19.0/27.9s is now a compact version chip on a dedicated green path, with the crossing copy wire hidden during delivery.
- Endings: baseline holds its final response from 22.1 to the 24.8s fade; Astra holds applied v8 from 24s and fades at 28s; Sol releases the later step at 28.3s and fades at 30.3s. These are deliberate reading holds, not timing guarantees. All exact first/last decoded frames match; none of the cuts demonstrates synchronous acknowledgement modes, failover or snapshot isolation.