Freezing a Subsystem
Stop at the smallest scope that solves the problem, and state what would justify going further.
Context
An observability layer had reached the smallest scope that makes an incident diagnosable from logs alone: one structured logger, automatic request correlation, deployment and build identity on every line, and slow-path visibility for both requests and database queries. Two further phases had been designed, splitting logs into categories, then choosing destinations, and neither had been built.
The system had no production traffic yet. Continuing to expand meant designing against imagined load rather than observed load, and every phase would have added configuration surface and failure modes to serve requirements nobody could yet describe.
Decision
Freeze the architecture at its current scope. Every element in it has a real, current consumer. The remaining phases stay valid designs, postponed rather than rejected, and the frozen shape is deliberately destination-agnostic, so adopting them later is a transport change rather than a redesign.
Options Weighed
- Continue into the designed phasesRejected
Their value is proportional to log volume and variety under real use, which did not exist. Building them would have added moving parts and configuration surface to serve needs nobody could describe.
- Freeze at the current scopeChosen
Everything in it earns its place, and the structure keeps every later option open at no cost.
- Reduce further and revisit the whole area laterRejected
Correlation and identity were already earning their keep. The question was only whether to extend, never whether to keep.
Consequences
- The system stays small enough to reason about, and every element in it has a current consumer.
- Real conveniences are deferred: no per-category separation, no volume control, no centralised search. Each stays cheap to add precisely because the foundation does not have to change to enable it.
- One feature was removed rather than kept, a sampling control that was inert at its default setting and carried a design question (which key? deterministic or random?) that could not be answered without traffic. Its interface was recorded as a seam worth preserving rather than a feature worth building.
- A related configuration model shrank from seven derived directories to two, once it was clear five existed only because a future feature might one day write there.
Cost of Not Deciding
Nothing forces a stop. Work continues into the designed phases because they are designed, and the system quietly acquires configuration surface, failure modes and maintenance cost for requirements it has never met. That cost is invisible while it accrues and is paid later, by whoever has to reason about the result.
Rollback
Free. Nothing was removed that cannot be added back, and the frozen scope was chosen specifically so that later work is a transport change rather than a redesign.
Evidence Required to Reopen
- A real incident, an operational constraint, or a measured cost demonstrates the need.
- Work that reopens this must reference this decision and record the production requirement that justified it. "We might need it later" is not sufficient.
Learned From
Derives From· 3
Related Knowledge· 1
Referenced By· 4
Version History
- v1.0.0
Accepted. Scope frozen; two designed phases postponed with the reopening rule stated.