As platform lead, what standing policy limit would you set on how far behind a broker client library may be?
answer
- decide once, not per release
- derive it from the served span
- unmeasured means unenforced
- no owner, no compliance
- refusal is an outage you chose
basics
~20 sPublish a floor expressed in releases or months behind, derived from the span your server release actually serves, then make it enforceable: a per-application report of who is below it, a dated cut-off, an owner for every client library, and refusal at connect as the final step.
solid answer
~50 sA floor with no report behind it is a wish. I would set the limit from what the platform itself serves - a client may be at most so many releases, or so many months, behind the running cluster, chosen to leave headroom before the server release that drops that shape arrives. Then I would make it real in four parts: a per-application inventory of client library version and owner; a standing report of who is below the floor; a dated cut-off communicated long before it bites; and, as the last resort, refusing connections below the floor, which is an outage you chose rather than one that chose you. The part organisations skip is ownership: an unowned client library cannot comply with any policy, so the policy has to force either an assigned owner with funded time or the application's retirement.
go deeper
Recall that organisations set a rule for how old a client library may be, and that the rule exists so the platform can take a new server release without asking every application first.
Explain where the number comes from: the span the server release states it serves, minus headroom, expressed in releases or months so a team can check its own dependency list against it.
Show that measurement is the hard part. Say how you would collect a per-application inventory, report compliance continuously, and handle the application that is already outside the span.
Own the trade and the escalation: a tighter floor buys the platform freedom at a recurring cost to teams, ownership must be forced rather than assumed, and refusal at connect is a chosen outage with named approvers.
## Why this has to be a standing rule Handled per release, old clients are always somebody else's emergency. The platform team discovers during upgrade planning that one application is three years behind, the application has no owner, and the choice is between delaying the cluster upgrade and cutting off live traffic with no notice. Both options are bad, and both were decided months earlier by not deciding. A standing rule moves the decision forward: **how far behind may a client library be, at any time, regardless of what upgrade is planned?** Answer it once, publish it, and the per-release conversation becomes routine. ## Choosing the number The floor is not arbitrary and it is not yours alone to invent. It is derived: - **Start from what the platform serves.** Each server release states how far back it will speak to clients - a number of releases on some platforms, a time span on others, a supported-client range on a rented cluster. That span is the hard outer bound. - **Leave headroom inside it.** If the floor equals the span, every application at the floor becomes an outage the day the next release lands. A floor comfortably inside the span gives teams a quarter or two of warning. - **Express it the way teams can check it.** "No more than N releases behind the running cluster" or "no older than M months" are both checkable from a dependency list; "reasonably current" is not. - **Say what the floor is for.** It exists so the platform can take a server release without negotiating with each application individually. ## What makes it enforceable | Element | Without it | |---|---| | A published floor | Teams cannot comply with a rule they have not read | | A per-application report of who is below it | The floor is unmeasured, so it is unenforced | | An owner recorded for every client library | Non-compliance has no addressee | | A dated cut-off, announced well ahead | The enforcement day is an incident | | Refusal at connect as the last step | The floor has no teeth and is ignored | The inventory is the part with real cost. Where the platform reports what each connection agreed, you can read current reality straight off the cluster. Where it does not, you fall back to each application's declared dependencies, which is weaker: it tells you what should be running rather than what is. ## The unowned library Every client-age policy meets the same wall: an application still serving traffic whose client library was pinned years ago and whose owning team no longer exists. No floor applies to it, because there is nobody the floor can address. The policy must therefore force one of three outcomes, and refuse the fourth: 1. **Assign an owner and fund the time.** Someone is made accountable for the dependency, with the upgrade paid for out of platform budget if necessary. 2. **Re-home the application** to a team that already owns something adjacent. 3. **Retire it** on a published date. 4. **Not this:** a permanent exemption. An exemption with no end date converts one team's neglect into a standing cost on every future cluster upgrade. ## Governing the enforcement itself Refusing connections below the floor is the only mechanism with teeth, and it is genuinely destructive, so treat it as a change that needs the same discipline as any other change made under traffic: - Announce the date far enough ahead that a normal delivery cycle can absorb the work. - Report compliance continuously between announcement and date, so nobody is surprised. - Name who may grant a time-boxed extension, and require an end date on every one. - Do the cut-off deliberately, not as a side effect of a server release that silently drops support - you want it on a day you chose. ## The trade you are making A tight floor costs application teams recurring upgrade work and buys the platform freedom to move. A loose floor costs the platform its ability to take releases and buys teams quiet. Neither extreme is right, and the honest principal answer says which way the organisation should lean and why: a platform that must take security releases promptly needs a tighter floor than one whose cluster is internal and rarely changes. What is never defensible is having no floor, because that is the same as promising every application indefinite support - a promise the platform cannot keep, and does not know it has made.
- How do you find out what client library versions are actually live?Prefer what the cluster reports: where the platform exposes the version each connection agreed, that is current reality. Otherwise fall back to declared dependencies per application, and accept that it tells you what should be running rather than what is. Either way the inventory is a standing artefact, not an upgrade-time exercise.
- Is refusing connections below the floor ever the right first move?No - it is the last step of a sequence. Announce a dated cut-off, report compliance continuously until it, grant only time-boxed extensions with named approvers, then enforce. Refusal without that sequence is indistinguishable from an unplanned outage, and it destroys the credibility the next policy needs.
- What would you do about an application whose client library has no owner at all?Force a decision rather than granting an exemption: assign an owner with funded time, re-home the application to an adjacent team, or retire it on a published date. An open-ended exemption converts one team's neglect into a permanent constraint on every future cluster upgrade.
saying these in an interview costs you the question
- Sets a floor and never reports who is below it.
- Assumes every client library still has an owning team.
- Cuts off old clients without a date anyone saw in advance.
- Treats the client inventory as knowable without collecting it.
- Waits for the release that drops support to force the decision.
- Grants exemptions with no end date attached.