skip to content

A downstream scoring service holds exactly one credential per account, so no overlap is possible — how do you rotate it?

level: principalimportance: should knowfreq 33%

answer

  1. move the overlap, or take a gap
  2. a second identity is the overlap
  3. one holder beats many holders
  4. quiesce the caller, not the service
  5. make it a requirement on new systems

basics

~20 s

Create the overlap somewhere else, or accept a gap: move callers to a second account on that service, put one component in front that holds the credential for everyone, or take a short planned interruption with the callers quiesced.

solid answer

~50 s

When the accepting system takes exactly one credential per account, the overlap cannot live where it normally does, so you choose which substitute you are paying for. **A second account** gives you a genuine overlap — both identities work, callers move, then the first is retired — at the cost of a duplicate identity with its own grants that someone must actually retire. **An intermediary** that holds the credential and fronts the service collapses the holder population to one process you can restart, at the cost of a new dependency on the call path. **A planned interruption** is honest and cheap when the caller is a nightly job you can pause: quiesce it, change both sides, resume. The estate-level move is the fourth: make "accepts two credentials at once" a requirement on what you build and what you buy, so this decision stops recurring.

go deeper

for a junior

Take away the fact that not every system can hold two credentials at once, which is why some rotations need a pause rather than a smooth handover.

for a middle

Be able to name the substitutes — a second identity, an intermediary that holds the credential, a planned pause — and what each one asks of the downstream.

for a senior

Choose between them for a specific caller, justify it by whether the caller can be quiesced and what the gap costs, and say how the old credential is retired.

for a principal

Set the default for the estate: classify downstreams by whether an overlap is possible, decide where to spend on an intermediary, and make two-credential support a requirement on what you adopt.

## Why this case is different The usual rotation relies on the accepting system holding two credentials for one identity while consumers move across. Some systems simply do not: one account, one credential, and setting a new one invalidates the old in the same instant. The mechanism is unavailable, so the question changes from *how long is the window* to *where else can the overlap live, and what am I willing to pay for it*. ## The four available shapes 1. **A second account.** Create a second identity on the downstream with the same rights, point callers at it, confirm nothing is using the first, then retire the first. This reproduces a true overlap — during the move, both work — using identities instead of credentials. 2. **An intermediary.** One component you control holds the real credential and every caller talks to it instead. The holder population drops from many processes to one, so a swap becomes a single restart with a gap measured in seconds, and the callers never see the credential at all. 3. **A planned interruption.** Stop the callers, change the credential on both sides, start them again. The gap is real but bounded and observed, and for a job that runs once a night between 02:00 and 02:20 it may cost literally nothing. 4. **Change what you accept.** Make the ability to hold two credentials a stated requirement for systems you build, and a question you ask of anything you adopt. This does nothing for today's rotation and everything for the next twenty. | Shape | What it buys | What it costs | Fits when | |---|---|---|---| | Second account | a genuine overlap | a duplicate identity and grants that must be retired | the downstream allows more than one account | | Intermediary | one holder, a seconds-long swap | a new component on the call path | many callers, a live request path | | Planned interruption | nothing to build | a real gap in service | the caller can be paused or queued | | Requirement on new systems | the problem stops recurring | no help today | you own the choice of downstream | ## Judging the case in front of you Two properties decide it. **Can the caller be quiesced?** A nightly job can be held back or its queue paused; a request path serving customers cannot, and a "brief" gap there is an incident with a nicer name. **What does a duplicate identity cost you over time?** A second account is only a clean answer if someone retires the first — an abandoned account with full rights and a credential nobody rotates is a worse position than the one you started in. For a scoring service called by a nightly job your team runs, the planned interruption is usually correct and the second account is over-engineering: pause the job, change both sides, run it, confirm. For the same downstream on a live request path, it inverts — the interruption is unacceptable, so you fund either the second account or the intermediary, and you decide which by whether the downstream supports more than one identity at all. ## The estate-level version A lead is not deciding one rotation; they are deciding a default. Classify downstreams by whether an overlap is possible, whether the caller can be quiesced, and what a gap costs: - Overlap possible: the ordinary rotation, no special handling. - No overlap, caller quiescible: planned interruption, in a named change window. - No overlap, live request path: fund an intermediary or a second identity — and count that cost against the downstream, because it is the downstream's limitation. That third bucket is the one to keep short, and the way to keep it short is procurement and design standards rather than heroics per rotation. ## Finishing the job Whichever shape you choose, the rotation ends the same way it always does: the old credential must stop working at the downstream. With a second account, that means retiring the first account, not merely ceasing to use it. With an intermediary, it means the swap actually happened at the downstream and not only in the intermediary's configuration. With a planned interruption, it happened by construction — the single credential was replaced. A plan that stops at "callers are on the new credential" leaves the old one live, which is exactly the outcome the rotation existed to prevent.

  • What does the second-account approach leave behind if nobody finishes it?
    Two live identities with equal rights on the downstream, one of them unused, unwatched and never rotated again. That is a worse position than the single credential you started with, so retirement of the first account has to be a named step with an owner, not an implied one.
  • When is a planned interruption the right answer rather than a workaround?
    When the caller is something you control and can pause or queue, the gap is bounded and observable, and the alternatives cost a permanent extra component or a duplicate identity. For a nightly job it is usually the cheapest correct answer; for a live request path it is not an answer at all.
  • What does putting an intermediary in front of the downstream change about the rotation?
    It collapses the holder population to one process, so the switch is a single restart rather than a fleet-wide move, and callers never hold the credential. You have bought a short, controllable gap and paid for it with a component that is now on the critical path.

saying these in an interview costs you the question

  • Claims any system can be made to accept two credentials at once.
  • Treats a second account as free once the callers have moved.
  • Plans an in-place swap on a live request path with no gap and no back-out.
  • Assumes callers can restart fast enough to hide the gap.
  • Leaves the first account live after moving callers to the second.
  • Calls the rotation done when callers are on the new credential.