When rotating a database password with both values accepted at once, how long should that overlap window stay open?
answer
- the slowest holder sets it
- measure, do not guess
- monthly job, monthly floor
- open window, rotation unfinished
- the window is also the back-out
basics
~20 sLong enough for the slowest legitimate holder to re-read and reconnect — usually set by the least frequent restart or batch run, and measured rather than guessed. No longer than that: until withdrawal the old value still authenticates.
solid answer
~40 sThe floor is the duty cycle of your slowest holder. If services redeploy every half hour, one job runs nightly and one runs monthly, then a two-day window covers the first two and misses the third entirely: that job still holds the old password and fails on its first run after withdrawal. So either the window stretches to a month, or you force the slow holder to re-read early. The ceiling is the cost of the window itself — while it is open, the value you are rotating away from still authenticates, so the rotation has bounded nothing yet. A window is a plan, not a clock the system enforces; nothing closes it but you, and the only thing that ends the old value's life is withdrawal at the database.
go deeper
Hold on to the shape: there is a period when both passwords work, and it has to last until the last thing that uses the old one has moved.
Be able to derive the floor from consumer duty cycles — deploy cadence, nightly runs, monthly runs — rather than quoting a standard number.
Show the arithmetic on a real mix of consumers, name the holder that sets the floor, and explain what the window costs while it is open and who owns closing it.
The lead's version is the default the estate uses when nobody measures, and what you require of consumers so that the floor is hours rather than a month.
## The window has a floor and a ceiling, and they pull opposite ways An overlap window is the period in which the accepting system — here a database — accepts both the outgoing and the incoming password for one account. Its length is not a policy number to be inherited from a template. It is bounded below by how long your consumers take to pick the new value up, and bounded above by the fact that the whole point of rotating is to stop the old value working. ## What sets the floor The floor is the duty cycle of the **slowest legitimate holder**, not the average one. Consumers pick up a new value at very different rates: - A service that re-reads on restart moves when it is next deployed or restarted. - A long-running process that read once at start-up and is never restarted does not move at all until something makes it. - A scheduled job moves on its next run — which may be tonight, or on the first of next month. - A standby or disaster-recovery instance may not have run since the last exercise. Work an example with real numbers. Suppose the request-path services redeploy on average every 30 minutes, one reconciliation job runs nightly at 02:00, and one settlement job runs on the first of the month. A 48-hour window comfortably covers the services and the nightly job — the services move within the first hour, the nightly job on its next run — and misses the monthly job completely, because the monthly job does not run inside those 48 hours. Withdraw at the end of that window and the failure arrives on the first of the month, days later, disconnected in time from the change that caused it. Your real options are a window long enough to contain a monthly run, or forcing that job to re-read early — running it off-cycle, restarting whatever holds its credential — so the floor comes back down to hours. ## What the ceiling costs It is tempting to answer "leave it open, nothing is broken". What a long window costs is exactly what the rotation was for: - **The old value still authenticates.** Whoever holds a copy — including whoever the rotation was prompted by — keeps working access for the length of the window. - **The change is unfinished.** A rotation with an indefinite window is two live credentials and no completion, which is how estates end up with accounts carrying several valid passwords nobody can attribute. - **Attention decays.** The longer the gap between publishing and withdrawing, the less likely the withdrawal is done by the person who understands the change, and the more likely it is skipped. | Window length | Symptom | |---|---| | Shorter than the slowest holder's duty cycle | withdrawal breaks that holder, often days later | | Matched to the slowest holder, then closed | the intended outcome: nobody notices the change, the old value dies on schedule | | Left open indefinitely | no outage, and no benefit — the old value is still a working credential | ## The window is also your back-out While both values are accepted, the change is reversible for free: if the new value turns out to be wrong, or a consumer reads it and misbehaves, you point that consumer back at the old value and it works. After withdrawal, reversing means re-adding a credential at the accepting side under whatever pressure you are now under. That is a real argument for not making the window artificially short — but it is an argument about the *switch-over*, not about the withdrawal, and it does not justify leaving the window open once everyone has moved. ## Nothing closes the window but you The window is a plan on a change ticket, not a timer the systems share. The store does not expire the old value; the database does not stop accepting it when your stated end time passes. It stops working when someone withdraws it, and if that step is not owned and scheduled it does not happen. Write the withdrawal into the change as its own step, with the check that precedes it — evidence that the old value is no longer being used — and an owner. A live exposure inverts the usual order and compresses all of this; that is its own decision and its own subject.
- Does a longer overlap window make the rotation safer?It makes the switch-over safer and the outcome later. Consumers get more time to move and the back-out stays free, but the old value keeps authenticating for whoever holds it for that whole period, so the risk the rotation was meant to reduce is simply deferred.
- A single monthly job sets a month-long floor. How do you get the window back down?Force that holder to move early rather than waiting for its schedule: run it off-cycle, or restart whatever process holds the credential so it re-reads. If neither is possible, the honest answer is that the window is a month — say so in the change rather than withdrawing on the plan's date and discovering it later.
- What should the change record contain so the withdrawal actually happens?Withdrawal as its own numbered step with a named owner and a date, the evidence required before it runs, and the back-out. A rotation whose last step is "new value published" reliably leaves two working credentials behind.
saying these in an interview costs you the question
- Picks a fixed window length without knowing the slowest consumer.
- Leaves both values accepted indefinitely and calls the rotation done.
- Assumes every consumer picks up the new value on its next request.
- Treats an open window as free because nothing is failing.
- Expects the old value to expire by itself when the window's date passes.