As the lead choosing what a cluster stamps on a stream created without stated values, which settings should have no default at all?
answer
- which settings may have a default at all
- a default decides for strangers, permanently
- mandatory where wrong is expensive
- long forms get copied from neighbours
- safest default multiplied by the estate
basics
~20 sSettings whose right value is workload-specific and costly to get wrong should have no default, so an absent value fails the request instead of being decided for someone. Everything else needs one, or the mandatory list grows until requesters copy another team's file.
solid answer
~50 sThe real decision is not what the defaults should be but **which settings are allowed to have one**. A default is a decision taken on behalf of every future team by someone who has not seen their workload, and it will not be revisited, so it should only cover values where one answer is right nearly always or where being wrong is cheap to correct. For the rest — the owning team, and whichever values are expensive or effectively irreversible on your platform — the request should carry no default at all and simply fail to apply when the field is missing. The counter-pressure matters just as much: make everything mandatory and the request becomes a long form, requesters copy a neighbouring team's file, and you get somebody else's guesses wearing the appearance of a deliberate choice.
go deeper
The core idea is that a default is still a decision — just one made by somebody else, in advance, for everybody. Knowing that much is enough at this level; the allocation of which settings get one is a lead's call.
Be able to argue both directions: why leaving a value defaulted spares people friction, and why a value that is expensive to get wrong is better off as a required field that fails the request when absent.
Bring the operating evidence: which defaulted values have turned up in your incident reviews, which mandatory fields are visibly being copied between teams, and what you changed as a result.
Own the allocation and its cost. Defend a short mandatory list, defaults recorded with rationale and a date, and a fast exception path, and price the safest-possible default against the whole estate before adopting it.
## A default is a decision you make for strangers Every creation-time default is a choice exercised on behalf of teams you will never meet, for workloads that do not exist yet, which nothing in the system will prompt anyone to re-examine. That is an unusual amount of leverage for a value set once during installation, and it is why this belongs on a platform lead's desk rather than in a runbook. The framing that makes the decision tractable is to stop asking "what number is right" and start asking **"who should be forced to decide this?"** Each setting lands in one of three places: - **Defaulted** — the platform supplies a value, the request may stay silent, nobody is blocked. - **Mandatory** — the request must state it, and an absent value is a hard failure rather than a silent fill-in. - **Defaulted with a ceiling** — a value is supplied, but a request may exceed it only through the exception path. ## The test for making something mandatory A setting earns mandatory status when all three hold: 1. **The right value genuinely varies by workload.** If one answer serves nearly every stream in the estate, forcing every requester to restate it is pure friction and teaches people to stop reading the form. 2. **Being wrong is expensive.** Expense here means either money at estate scale or a failure the value exists to prevent. 3. **Correcting it later is materially harder than stating it now.** How true that is varies by platform and by value, which is why the mandatory list is not portable between organisations. The owning team passes all three trivially and is the one field that should be mandatory everywhere: it costs a word to state, it cannot be reconstructed from anything the platform stores, and its absence is what turns an unused stream into one that stays forever. ## Why "make everything mandatory" fails The instinct after a bad incident is to require everything. It backfires predictably: - A long request is filled in by **copying a neighbouring team's file**, so the values are somebody else's guesses — and now they look deliberate, which is worse than an obvious default, because the next reviewer assumes somebody thought about them. - The declared path gets slower, and a slow path gets routed around. - Every field looks equally important, so the two that genuinely matter stop standing out. A short mandatory list is filled in honestly. A long one is filled in by rote. **The mandatory list is a budget, not a wish list.** ## Why "default everything to the safest value" also fails The mirror-image instinct is to make each default the most conservative value available. This is not free: | Choice | Looks like | Actually costs | |---|---|---| | Maximum durability by default | Prudence | Storage and write cost multiplied across every stream, most of which carry nothing critical | | Very long retention by default | Safety | Volume pressure, and a larger set of records in scope when somebody asks what you hold | | Generous parallelism by default | Headroom | Reserved capacity per stream and, on a rented cluster, a bill that scales with it | A default multiplied across an estate is a standing cost with no owner. The workable posture is a default that is **safe enough to be defensible on the day it is questioned, and cheap enough to survive being applied thousands of times** — with the genuinely consequential value moved out of the defaults entirely and into the mandatory list. ## Policy for an estate that outlives its teams The principal-level version of this answer has three parts: 1. **Write the defaults down with their reasoning and a date.** A value with a recorded rationale can be argued with; a value with no author can only be inherited. 2. **Keep the mandatory list short and re-derive it when the platform changes.** What is expensive to change is a property of the platform and the tier, and it moves when either does. 3. **Give the exception path a real route.** If exceeding a default requires a review, that review must be fast, or the band becomes a ceiling in practice and teams quietly design around it. The aim is not perfect values. It is that **every value that matters has a name attached to it**, and every value that does not is cheap enough that nobody needs to care.
- Is there any setting that should be mandatory on every platform, regardless of the rest?The owning team. It costs one word to state, it varies for every single stream, it cannot be recovered from anything the platform itself records, and its absence is precisely what makes an unused stream impossible to retire with confidence later. Nothing else clears all four bars so cleanly.
- How would you tell whether your mandatory list is the right length?Look at the submitted requests rather than the policy. If a field's values cluster on one number that nobody can explain, it is being copied and belongs back in the defaults. If a defaulted value shows up in incident reviews as a contributing factor, it belongs in the mandatory list.
- Does a rented cluster change the answer?It narrows it. Some values are fixed by the tier and are not yours to default or require, so the mandatory list shrinks to what you still control — typically the owning team and whatever the tier exposes. It also sharpens the cost argument, because a generous default becomes a line on an invoice.
saying these in an interview costs you the question
- Thinks a sensible default exists for every setting
- Requires twenty stated values and calls it governance
- Treats the most conservative default as automatically the responsible one
- Sets defaults once without recording who chose them or why
- Assumes the mandatory list transfers unchanged to another platform
- Forgets that a default is multiplied by every stream in the estate