system design · high

Architecture & Project Ownership — Lifecycle, ADRs, Tech Debt, Interview SAR

Architecture and project ownership. Full lifecycle: Phase 1 Discovery (business goals + NFRs + scope pruning); Phase 2 Design (ADRs, critical path mapping, failure mode planning); Phase 3 Delivery (independently shippable milestones, own interfaces); Phase 4 Maintenance (observability day 1, runbooks, versioned APIs, tech debt cadence). ADRs (Architecture Decision Records): Title, Status, Context, Decision, Alternatives-Rejected, Consequences; commit to repo; 'next engineer can understand why without calling you.' Architecture selection: NFRs first; simplest solution that meets them; complexity is a liability; microservices = last resort (massive overhead). Observability pillars: metrics (P50/P99/P999 histograms), logs (async, structured, trace IDs), alerts (actionable). Tech debt tiers: fix-now (security/corruption), fix-next (measurable perf), accept-risk (document). Interview: SAR format — Situation + Action (what + what rejected) + Result (quantified).

The code

// Architecture & Project Ownership — interview framework

// ADR (Architecture Decision Record) format:
// Title:       Use CQRS for order processing service
// Status:      Accepted (2025-03)
// Context:     Read queries 10x more than writes; query latency SLA < 10ms
// Decision:    Separate read model (denormalized, eventually consistent)
// Alternatives: Single model → write contention; Redis cache → stale data
// Consequences: Eventual consistency accepted; read model sync via events

// Product lifecycle phases:
// Phase 1: Discovery  → business goals + NFRs (not features)
// Phase 2: Design     → ADRs, critical path, failure mode planning
// Phase 3: Delivery   → milestones (each independently shippable)
// Phase 4: Maintenance → observability on day 1; runbooks; tech debt cadence

// Architecture selection rule:
// SIMPLEST solution that meets NFRs wins
// Complexity is a liability, not a feature

// Critical path planning:
// Before writing code: draw the request flow
// Mark each step: OK-to-fail vs must-not-fail
// Budget latency for each step on critical path
// Plan failure modes before they happen

// Observability must-haves from day 1:
// - Latency histograms (P50, P99, P999)
// - Throughput counter (events/sec)
// - Error rate + error types
// - Resource utilization (CPU, memory, queue depth)
// - Health endpoint (/health returning 200 when ok)

// Tech debt framework:
// Tier 1: Fix now         — security holes, data corruption risk
// Tier 2: Fix next cycle  — performance debt, test coverage gaps
// Tier 3: Accept risk     — cosmetic issues, low-traffic paths

// API versioning rule:
// v1/v2 in URL or Accept header
// Deprecate: announce → provide migration path → maintain 2 versions → remove
// Never break consumers without notice + migration period

What this lesson walks through

1. 01Full product lifecycle — from discovery to maintenance
2. 02ADRs — Architecture Decision Records
3. 03Architecture selection — simplest solution that meets NFRs
4. 04Observability — metrics, logging, alerting from day 1
5. 05Tech debt management — triage framework
6. 06Interview delivery — the 'walk me through a key decision' question

Senior engineers are asked: 'walk me through how you manage a product from start to finish'. Interviewer is checking: do you think only in code, or do you own the full lifecycle? Answer with 4 phases. Phase 1 (Discovery): meet stakeholders, extract business goals and NFRs, challenge every requirement. Phase 2 (Design): choose architecture based on NFRs, document decisions with ADRs, identify critical path. Phase 3 (Delivery): milestones independently shippable. Phase 4 (Maintenance): observability day 1, runbooks, tech debt cadence.