Operational Complexity

The Cost That Compounds Forever

Every architectural choice has a build cost paid once and an operating cost paid forever. Diagrams show the first; pager rotations live inside the second:

 EACH NEW COMPONENT ADDS TO:
 - deploy pipeline        (one more thing to release safely)
 - monitoring             (dashboards, alerts, thresholds to tune)
 - failure modes          (it can be down, slow, or silently wrong)
 - upgrade treadmill      (versions, CVEs, breaking changes)
 - runbook + on-call      (someone must know it at 3am)
 - debugging surface      (one more suspect in every incident)

 a 6-component system isn't 20% more work than 5 —
 INTERACTIONS multiply: n(n-1)/2 potential pairwise failure conversations

Where Operational Complexity Actually Bites

Source	Typical manifestation
Too many stores	”which DB owns this field?” archaeology during incidents
Exotic tech	Only one engineer understands it; they resign; knowledge leaves
Microservice sprawl	Cross-service latency hunts for bugs one process would reveal
Config sprawl	Nobody can state production’s actual behavior from memory
Alert noise	Real pages drowned; fatigue normalizes ignoring them

The pattern behind all five: complexity exceeds the team’s comprehension budget — and incomprehensible systems fail in unrecoverable ways.

The Complexity Budget

Treat comprehension as finite capital and spend it deliberately:

 SPEND ON:                        REFUSE TO SPEND ON:
 - the core hard problem          - resume-driven components
   (matching, consensus, feed       (a second message queue because
    ranking — wherever your          "Kafka vs Rabbit" felt undecided)
    differentiation lives)         - infrastructure before trigger
 - one exotic piece at a time       metrics justify it
   with a named owner            - tools solving problems you
                                   don't have yet

Boring technology is not an aesthetic preference — it is accumulated community operational knowledge: known failure modes, existing dashboards, hireable expertise. Exotic means learning its failure modes in production, alone.

Managed Services: Renting Away the Tax

Managed offerings convert operational cost into financial cost:

 SELF-HOSTED Postgres           MANAGED Postgres
 backups: your scripts          automated PITR included
 failover: your runbook         button/API, tested by vendor
 upgrades: your maintenance     rolling, mostly invisible
 on-call: your 3am              their 3am (you page support)
 
 price tag: real but usually < ONE avoided incident's engineering cost
 at small/mid scale, managed wins nearly always;
 at very large scale or special requirements, the math can flip

This is build-vs-buy applied specifically to operations rather than capability.

Reducing Existing Complexity

Complexity already aboard can be paid down deliberately:

• Delete unused components (highest-value ops move available).
• Consolidate overlapping stores (two caches → one).
• Standardize deployment/observability patterns so each component costs less marginal attention.
• Document death stories: per component, what failure looks like and the first three checks.

Interview Framing

Interviewers grade operational awareness through follow-ups: “who operates that?” “what alerts exist?” Strong candidates pre-empt with budget language (“I’d rather keep one Postgres than add Cassandra here — our complexity budget goes to matching”) and mention managed options when proposing stateful pieces. Naming the tax explicitly is what separates operators from diagram artists.