Retire the model only after its consumers and delayed work migrate
Treat retirement as a dependency transition covering aliases, pinned artifacts, batch jobs, in-flight requests, delayed labels, and rollback obligations.
On this page
The question for today
What you’ll understand
- Inventory direct and indirect consumers of a model version.
- Calculate a conservative retention boundary under explicit bounded-work assumptions.
- Distinguish changing a registry pointer from completing consumer migration and data retention.
A model stops receiving ordinary web traffic long before every dependency necessarily stops using it. Scheduled batch jobs can pin its artifact, workers can hold it in memory, retries can reappear, and delayed labels can still need its historical predictions. Retirement is therefore a state transition across a dependency graph, not a delete button. Plan migration evidence, rollback readiness, and retained evaluation records before removing the serving capacity or artifacts that those obligations require.
Find consumers beyond the obvious endpoint
Inventory endpoint callers, model aliases, explicitly pinned versions, batch configurations, notebooks promoted into jobs, offline feature builders, and services that consume the model's outputs as features. Record owners, compatibility contracts, traffic schedules, and maximum work durations. A new model can preserve its output shape while changing class order, units, calibration, or score meaning, so consumer migration includes semantic compatibility. Historical logs can reveal callers absent from an ownership list, but observing no recent traffic does not prove a monthly or rarely triggered workflow has disappeared.
Registry aliases provide indirection, not universal invalidation. A process that loaded an artifact can retain it until its next reload or restart, while another caller may bypass the alias with an explicit version. Log the resolved artifact identity at execution time and verify the deployed consumer configuration. TensorFlow Serving version policies and labels illustrate that serving selection is a separate configuration surface from a training registry. Updating one control plane does not establish that every endpoint, worker, scheduled job, and cached client has transitioned.
Drain work and keep the necessary recovery boundary
Stop admitting new work to the old version, then track in-flight requests, retry queues, asynchronous workflows, and scheduled jobs under explicit bounds. Measure terminal completions rather than assuming a routing change canceled work already accepted. A conservative artifact-retention rule can combine the latest possible old-version work completion with a rollback interval, when the rollback interval is explicitly required after that completion. If timers overlap instead, a different maximum applies. State each time origin so adding durations does not hide an unsupported assumption about when obligations begin.
Serving artifacts, historical prediction records, and sensitive raw inputs can have different retention requirements. Keeping a prediction and its artifact identity may allow a delayed label join without retaining a live endpoint; reproducing the original computation may additionally require the immutable model, preprocessing, and environment. Specify which capability is required and keep only the data and artifacts needed under the applicable policy. If any old-version workflow has unbounded retries or unknown ownership, no finite arithmetic deadline proves complete retirement; resolve or explicitly terminate that dependency first.
Prove migration with identities, cohorts, and failure drills
Use resolved-version metrics and representative scheduled executions to verify migration, including rarely active consumers. Reconcile requests by version rather than relying on an endpoint's display name. Test how a consumer handles an unavailable old version and whether its fallback is semantically compatible. Preserve a retirement record containing the consumer inventory, migration evidence, final serving configuration, rollback decision, and artifact-retention policy. Monitor for old-version access after retirement so a forgotten caller becomes an observable migration failure rather than silently receiving a different model.
The queue instrument supplies a small draining analogy. Reset, set λ=0 and μ=2, predict that its initial backlog four reaches zero after two seconds, then take four Steps. Separately Reset, set λ=1 and μ=2, predict backlog two after two seconds, then take four Steps. The model recomputes from its initial backlog for each fixed rate pair; it does not preserve a history when controls change. It has no retries, consumer discovery, artifact aliases, or bounded-job proof. Reaching zero in this toy cannot certify that a real retired model has no hidden work.
Work it through
Compute a deadline from explicit time origins
The last possible old-version admission is Monday 12:00. Remaining work, including retries, is guaranteed to finish within six hours. Policy requires retaining the artifact for twenty-four hours after the latest possible completion. A separate reproduction obligation requires that same artifact through Wednesday 00:00. Find the earliest deletion time under these assumptions.
The latest permitted old-version completion is Monday 12:00 plus six hours, or Monday 18:00. Confirm that the six-hour bound includes every accepted workflow and retry path.
The stated rollback policy starts after that completion boundary, so its deadline is Monday 18:00 plus twenty-four hours, or Tuesday 18:00.
Compare absolute deadlines: the later of Tuesday 18:00 and Wednesday 00:00 is Wednesday 00:00. Keep the artifact at least until that point, provided the consumer-migration and draining evidence also hold.
Wednesday 00:00 is the arithmetic lower bound for artifact deletion under the explicit assumptions. Historical prediction records and other retained data have their own policies.
The living notebook
Explore the model
Interactive lab · queue
Stopping admission differs from changing a routing label
Reset, set λ=0 and μ=2, predict backlog 0 after t=2 s, then take four Steps. Separately Reset, set λ=1 and μ=2, predict backlog 2 at t=2 s, then take four Steps. The fixed-rate fluid model starts at backlog 4; controls retain elapsed time, so use Reset for each comparison. It does not represent retries, hidden consumers, or proof of retirement.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forRetirement needs evidence that old-version admission and outstanding work have both ended.
Pause & reason
Check your understanding
Your turn
Try it yourself
At hour zero, admission to the old version stops. All accepted work has a verified maximum remaining duration of three hours. Policy retains its artifact for twelve hours after the latest possible completion, and an independent artifact reproduction deadline is hour twenty. Find the earliest permitted deletion hour and explain why zero traffic in the last hour would not replace the dependency inventory.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Compare the work-plus-rollback deadline with the absolute reproduction deadline.
Compare with the solution
The work-plus-rollback boundary is 0+3+12=15 hours. The independent deadline is hour twenty, so deletion is no earlier than hour twenty, assuming every required migration and draining check passes. A quiet hour cannot rule out pinned batch jobs, delayed retries outside an unverified bound, or rarely used consumers; the inventory and bounds need explicit evidence.
Keep the idea
Take it with you
- Retirement spans aliases, pinned consumers, indirect dependencies, and delayed work.
- Retention arithmetic needs explicit bounds and time origins for each obligation.
- A routing update and a quiet dashboard do not prove consumer migration is complete.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.