Several teams each wrap a push feed that cannot be slowed — what standard do you set for their adapters?
answer
- uniform invariants, local policy
- no silent default
- declared loss, counted loss
- no unbounded hold anywhere
- review the consumer, not the feed
basics
~20 sStandardise the invariants, not the policy: no adapter exceeds outstanding demand, every loss policy is declared rather than emergent, discards are counted and exported, and no hold is unbounded. Which policy each feed uses stays with the team that owns its consumer.
solid answer
~50 sA platform standard here fails in one of two ways. Mandate a single policy and it will be wrong for most feeds, because the right loss depends on what each consumer computes, not on the feed. Mandate nothing and every adapter improvises under pressure, usually into an unbounded hold. So standardise the properties every boundary must have: demand is never exceeded; the policy is an explicit, required choice with no silent default; discards, overwrites and high-water marks are counted and exported; no hold is unbounded anywhere in the adapter; and the consumer can distinguish a quiet period from a period whose values were dropped. Then delegate the actual choice, the bound and the cadence to the team that owns the consumer, since only they know what the number is for. Ship it as a component, not a document.
go deeper
Know that wrapping a source that cannot slow always involves a choice about what to lose, and that the choice belongs in the code rather than in someone's head.
Be able to say why the right policy differs per feed, and which properties — honouring demand, bounding holds, counting loss — should not differ at all.
Argue for a shared boundary component that makes the policy explicit and exports its cost, and name what you would check in review.
Draw the line between what is uniform and what is local, defend it with the incident it prevents, and refuse the convenient default that hides the decision.
## Why a single mandated policy is the wrong standard Every boundary over an unslowable source makes the same decision — what happens to a value that arrives with no outstanding demand — and the correct answer depends entirely on what the downstream consumer computes. A consumer summing events cannot lose one; a consumer drawing current state cannot use an old one; a consumer plotting a trend wants regular spacing more than completeness. A platform rule of the form "all adapters keep only the latest" is therefore guaranteed to be wrong for a substantial share of feeds, and it will be wrong invisibly: the totals will simply be low. The opposite failure is just as predictable. With no standard, each team invents flow control at the moment it hurts, under incident pressure, and the result converges on the one option that looks free at three in the afternoon — an unbounded hold. That defers the decision to whichever night the source bursts. ## What belongs in the standard The things worth making uniform are the properties that make any policy trustworthy, not the policy itself: 1. **Demand is never exceeded.** The adapter emits only within outstanding demand. This is the guarantee every downstream stage is sized against, and it is not negotiable per feed. 2. **The policy is declared, not emergent.** It is a required, named choice recorded where the adapter is constructed — readable without tracing the code. 3. **Loss is counted and exported.** Discards, overwrites, hold depth, high-water mark, breaches. Anyone asking "is this number complete?" should answer it from telemetry rather than from source. 4. **No hold is unbounded.** Anywhere in the adapter. A bound may be large; it may not be absent. 5. **Gaps are distinguishable from silence.** Where the consumer can act on it, a lossy stream carries enough signal — a skipped count, a gap marker — that a quiet period is not mistaken for a complete one. | Uniform across the platform | Delegated to the owning team | |---|---| | Demand is honoured exactly | Which policy the feed uses | | A policy must be chosen explicitly | The size of any bound | | Discards and depth are exported | The cadence, where one applies | | No unbounded hold | Whether a breach fails or degrades | | Loss is visible to the consumer | How the consumer reacts to a gap | ## The silent default is the specific trap The natural way to roll this out is a shared boundary component. The natural way to make it pleasant to use is to give it a sensible default policy. That default is the failure mode: it converts a decision that should be made once per feed, by someone who knows what the feed is for, into a decision nobody made at all — and it will be invisible in every review, because a default does not appear at the call site. Make the policy a **required** argument with no default. The friction is the point: it costs a few seconds and it forces the one conversation that matters. Where the choice is genuinely obvious, it costs nothing to state it; where it is not, the argument is exactly where the discussion should surface. ## Make the standard cheaper to follow than to bypass A standard enforced only by a document decays. The version that survives is the one where the shared component does the tedious parts for free: - demand accounting, correct once, in one place; - the counters, exported without anyone wiring them; - a breach path that fails the way the team chose rather than the way the runtime happens to; - a review question with a single answer to check — does the declared policy match what the consumer computes? ## What you are really buying The payoff is not tidiness. It is that when a total is questioned months later, the answer is available: this adapter was configured to hold up to n values and to fail on breach, it breached twice, here are the timestamps. Without the standard, the same question ends in an archaeology exercise across several teams' adapters, each of which handled pressure differently and none of which recorded that it did. The judgment a lead is actually being asked for is where to draw that line between uniform and local — and the defensible line is that **correctness properties are uniform and loss preferences are local**.
- How do you stop the standard from becoming a document nobody reads?Put it where the code is. A shared boundary component that makes the policy a required argument, exports the counters for free and fails on a breach the way the team chose costs less to adopt than to bypass. The document then only records the reasoning; the component records the rule, and review has a single checkable question.
- What exception to the no-loss-without-a-declared-policy rule would you allow?A feed whose consumer needs every value and whose burst is bounded by something outside the pipeline — a fixed guest list, a closed batch. A hold sized to that bound is exact rather than lossy, so no loss policy fires in practice. The exception still declares the bound and still fails on a breach, because whatever bounded the source can change without telling you.
saying these in an interview costs you the question
- Mandates one loss policy for every feed on the platform
- Ships a shared adapter whose default policy nobody chose
- Measures adapters by throughput and never by discards
- Leaves each team to write its own demand accounting
- Accepts an unbounded hold while memory currently looks fine