skip to content

Your platform adds cross-cutting behaviour by wrapping, and teams keep shipping paths it silently skips, so what do you standardise?

level: principalimportance: should knowfreq 30%

answer

  1. the failure mode is silence
  2. decide per concern, not per codebase
  3. fail-open concerns need another carrier
  4. the boundary as a stated rule
  5. a build-time check beats a convention

basics

~20 s

Standardise around the failure mode: wrapping fails silently. Classify each concern by what a silent miss costs, keep the ones that must never be absent off a mechanism that can quietly not apply, and make the guarantee checkable instead of assumed.

solid answer

~40 s

Start from the property that causes the bugs: when a stand-in does not apply, nothing reports it and the call simply proceeds. So the first decision is **per concern**, not per codebase. Caching, timing and retry tolerate a silent miss; authorisation and audit do not, and I would not let those ride on wrapping alone, they belong at an entry point every path provably crosses or in the code itself. Second, make the boundary an explicit design rule: wrapped behaviour applies to calls that cross a module boundary, so nobody expects an internal call to carry it. Third, make it checkable, because an automated check that fails the build on a bypassing call beats a convention that is remembered for a quarter.

go deeper

for a junior

Recall that the danger of this mechanism is not that it errors but that it quietly does nothing, so nobody notices the path it missed.

for a middle

Explain why a coverage gap cannot be seen in the member's declaration, and what kind of test would actually reveal one.

for a senior

Show how you would find the bypassed paths in an existing system and restructure the highest-cost ones first.

for a principal

Decide per concern which guarantees may ride on a mechanism that fails silently, state the boundary rule that makes coverage predictable, and make it enforceable rather than remembered.

## Start from the failure mode, not from the fix The recurring bug is not that a particular team wrote a particular call badly. It is that this mechanism's failure mode is **silence**. When a call reaches the stand-in, the behaviour runs; when it does not, the call succeeds without it and nothing anywhere reports the difference. Every other property of the technique follows from that: it is easy to adopt, pleasant to read, and impossible to audit by inspection. A lead's job here is not to teach every team the mechanism a third time. It is to decide where a silent failure is acceptable, and to make the places where it is not acceptable structurally different. ## Classify concerns by the cost of a miss The first standard is a table, not a technique. | concern | what a silent miss costs | may it ride on wrapping alone? | |---|---|---| | caching, memoisation | slower, still correct | yes | | timing, metrics | a gap in a chart | yes, with a coverage check | | retry, back-off | a failure surfaces that would have been absorbed | yes, if the caller handles failure anyway | | audit, compliance records | an event that legally had to exist does not | no | | authorisation, tenancy isolation | an unguarded call proceeds | no | The top rows degrade. The bottom rows fail open, and a mechanism that fails open silently is the wrong carrier for them, however convenient. Those belong at an entry point that every path demonstrably crosses, or written explicitly into the operation that needs them, where their absence is visible in the code under review. ## Make the boundary a rule rather than a habit The second standard is a stated architectural rule: **declared cross-cutting behaviour applies to calls that cross a boundary, and nothing else**. That single sentence removes the whole class of surprise, because it tells a reader what to expect without knowing how the stand-in is produced. Its corollaries are the useful part: - A member that carries such a declaration is called from outside its own object, never by the object on itself. - Members expected to be wrapped stay replaceable and reachable; a declaration on a member the structure cannot reach is a defect in the declaration. - Identity is not part of any published contract, so no lookup keys on a reference that a later layer may replace. ## Make the guarantee checkable The third standard is that nobody has to remember the second one. 1. **A build-time check** over the code that fails when a member carrying such a declaration is called by its own object, or when the declaration sits on a member that cannot be intercepted. This is the highest-leverage item on the list and the one most often skipped. 2. **A startup assertion** that the references handed out for the wrapped concerns really are the stand-ins, so a wiring mistake surfaces at boot rather than in production. 3. **Behaviour that leaves a trace.** A stand-in that produces nothing observable when it runs cannot be distinguished from one that did not run. Whatever the concern, it should emit something a test can assert on. 4. **Tests that drive the outer path.** Coverage is a property of call paths, so tests asserted on the entry point that real callers use, not on the member itself. ## Write the decision down, including the tolerated gaps The last piece is a record. For each concern, the standard should say whether a missed application is tolerated, and if so, why. A cache bypassed on an internal path is a documented performance characteristic; the same gap undocumented is a latent incident that someone will eventually diagnose from scratch. The distinction between a **tolerated** gap and an **unnoticed** one is almost the whole value of writing the standard at all. ## Why this is a lead's call and not a team's A single team can fix the bug in front of it by restructuring one call. Only someone looking across teams sees that the same fix is being rediscovered, that the concerns most often bypassed are also the ones whose absence produces no signal, and that the mechanism is being asked to carry guarantees it was never able to make. The judgment being exercised is not about wrapping; it is about which guarantees an organisation is willing to obtain from a mechanism that fails quietly, and that decision has to be made once, for everyone, and revisited when the stakes of a concern change.

  • What signal would you require before trusting that the behaviour applied on a given path?
    Evidence the behaviour itself produced, asserted from that path: a record, a counter, a timing sample. A stand-in that leaves no trace when it runs is indistinguishable from one that never ran, and that indistinguishability is the entire problem, so the first fix for an unverifiable concern is to make it observable.
  • Would you ever accept the gap instead of closing it?
    Yes, where the cost is bounded and visible. A cache bypassed on an internal path is slower, not wrong, and forcing a restructuring to recover it can cost more than it saves. What is not acceptable is an unrecorded gap, because then nobody can tell a tolerated miss from an undiscovered one.

saying these in an interview costs you the question

  • Treats every cross-cutting concern as equally safe to apply by wrapping.
  • Relies on review and convention to catch a silent, path-dependent gap.
  • Offers one project's workaround instead of a rule other teams can apply.
  • Assumes tests written from outside prove the behaviour applies everywhere.
  • Accepts a carrier whose absence produces no signal for an audit requirement.
  • Proposes banning the mechanism outright rather than scoping where it is trusted.