# 8. The rolling-window proof [← 7. The backfill window bug](07-the-backfill-window-bug.md) · [Next: 9. The contract migration →](09-the-contract-migration.md) Every rolling deploy in this sequence — Deploy 2, Deploy 3, Deploy 4a — has a window where two adjacent stages are serving real traffic against the same database at the same time. [`MixedStageRollingWindowTest`](https://ankurm.com/git.app/asmhatre/spring-boot-demo/src/branch/main/db-migrations-expand-contract/src/test/java/com/ankurm/expandcontract/MixedStageRollingWindowTest.java) is the property this whole article rests on, checked directly: it builds two `CustomerService` instances on adjacent stages sharing one database, and cross-checks every write/read direction across all three rollouts. ``` -- Stage 1 writes, Stage 2 reads -- Customer[id=1, name=Radia Perlman, email=radia@example.test] -- Stage 2 writes, Stage 1 reads -- Customer[id=2, name=Barbara Liskov, email=barbara@example.test] -- Stage 2 writes, Stage 3 reads -- Customer[id=3, name=Shafi Goldwasser, email=shafi@example.test] -- Stage 3 writes, Stage 2 reads -- Customer[id=4, name=Frances Allen, email=frances@example.test] -- Stage 3 writes, Stage 4 reads -- Customer[id=5, name=Adele Goldberg, email=adele@example.test] -- Stage 4 writes, Stage 3 reads -- Customer[id=6, name=Karen Sparck Jones, email=karen@example.test] ``` Full transcript: [`docs/output/08-mixed-stage-rolling-window.txt`](https://ankurm.com/git.app/asmhatre/spring-boot-demo/src/branch/main/db-migrations-expand-contract/docs/output/08-mixed-stage-rolling-window.txt). Six pairs, six passing reads. If any one of them failed, the technique would not be zero-downtime for that rollout — it would just be a race against however long the rollout takes to finish, with correctness depending on luck rather than design. The diagram is the same shape three times because the guarantee is the same three times: whichever two stages are live together during a given rollout, a write from either one has to be readable correctly by the other. That's what the test above checks directly, and it's what the article's live 4-deploy run — a real load generator, hitting real HTTP endpoints, during a real rolling restart — is reproducing under actual timing pressure rather than a unit test's controlled ordering. ## Going deeper - The live version of this proof, with two real replicas and continuous HTTP traffic: [chapter 11](11-the-load-generator.md) and the full run in [`docs/output/11-live-deploy-sequence.txt`](https://ankurm.com/git.app/asmhatre/spring-boot-demo/src/branch/main/db-migrations-expand-contract/docs/output/11-live-deploy-sequence.txt). [← 7. The backfill window bug](07-the-backfill-window-bug.md) · [Next: 9. The contract migration →](09-the-contract-migration.md)