Fable architecture

Fable Architecture

Core thesis: architecture is deciding what will be cheap to change and what you can afford to fix in place. A design is not good because it is elegant on a whiteboard; it is good because the constraints are real, the failure modes are named, and the next team can evolve it without archaeology.

1 — Constraints before shapes

No boxes and arrows until the load-bearing numbers exist. Force them:

• How many: users, requests/sec, rows, events/day — today and at 10×.
• How fast: latency budgets per operation; what is interactive vs batch.
• How consistent: what must be transactionally true vs eventually true vs best-effort. Name the money paths and the audit paths.
• Who operates it: team size, on-call maturity, deploy cadence, cost ceiling, compliance boundaries.

"High scale" is not a number. If the user cannot supply numbers, propose defensible assumptions, label them, and design to them — visibly.

Checkpoint — Constraint sheet: the numbers, the consistency map, the operational reality. Every later choice must cite one of these or admit it is taste.

2 — Find the axis of change

Boundaries exist to contain change. Ask: what will churn (requirements, integrations, UI, pricing rules) and what is stable (identity, the core domain, the ledger)? Put boundaries where change is contained, not where the org chart or the framework suggests. The corollary: things that change together live together — splitting them is how distributed monoliths are born.

3 — Alternatives with champions

Generate two or three genuinely different architectures — not one design with three database vendors. For each: sketch honestly, steel-man it, score it against the constraint sheet (not against fashion). The rejected design must have had a real champion; if you cannot argue for it convincingly, you have not explored it.

Novelty budget: you get a small number of innovation tokens. Spend them only where the product differentiates; everywhere else, choose boring, proven, operable technology. Excitement is a cost center.

Checkpoint — Decision record (ADR): context, options considered, decision, consequences — including what this makes hard — and a revisit trigger ("re-evaluate when X exceeds Y"). A decision without stated consequences is an opinion.

4 — Design the failures

The happy path is the easy 20%. Before the design is done:

• What breaks first under load, and what is its blast radius?
• Degradation modes: what does the user see when each dependency is down? Degraded and honest beats up and lying.
• Every network call gets a verdict: timeout, retry policy (with backoff and a cap), idempotency story. Retries without idempotency are a duplication engine.
• Backpressure: when the queue grows, who slows down, and who gets told?
• The recovery question: after a crash mid-operation, how does the system know what is true? (This is where the data design earns its keep.)

5 — Data first, state contained

• Schema, ownership, and lifecycle before service shapes: one writer per fact; everyone else reads or subscribes. Shared mutable tables as integration is a coupling trap with a delay fuse.
• State is the hard part — minimize the components that hold it. Stateless tiers are a gift to operations; treat every new stateful component as a liability that must justify itself.
• Model the domain's invariants in the schema where the database can enforce them (constraints, uniqueness, foreign keys) — not only in application code.

6 — The migration path is part of the design

A target architecture without shippable steps from here is fiction. Deliverable-sized increments, each leaving the system working; reversible early steps before one-way doors; explicit one-way doors marked as such and taken consciously. If the plan's first step is "freeze everything for a quarter", the plan is wrong.

The rubric

Score 0–2 each before delivering (feeds the fable-core Gauntlet). Any 0 blocks delivery.

1. Constraint grounding — decisions cite numbers and named constraints. Test: pick any component; which constraint put it there?
2. Real alternatives — a rejected option existed and had a champion. Test: state the strongest argument for the loser without weakening it.
3. Boring budget — novelty spent only on differentiators. Test: list every non-boring choice and its justification.
4. Boundary placement — change is contained. Test: name the three likeliest change requests; how many boundaries does each cross?
5. Failure honesty — modes, blast radius, degradation named. Test: for each dependency, what does the user experience when it is down?
6. Data ownership — one writer per fact; invariants enforced where reality checks them. Test: pick a fact; who writes it, who can corrupt it?
7. Operability — observability, deploy, rollback are designed, not assumed. Test: how do you know it's broken before the users tell you?
8. Evolvability — migration steps are shippable; revisit triggers exist. Test: what ships in the first two weeks?

The anti-pattern catalog

Check by name in the Gauntlet:

1. Resume-driven design — technology chosen for its aura → back to the constraint sheet; spend the novelty budget on differentiators only.
2. Premature microservices — network boundaries inside one team's one domain → modular monolith until scale or team topology demands the split.
3. Whiteboard optimism — an architecture with no failure modes drawn → run section 4; a design that cannot fail was never designed.
4. Distributed monolith — services that deploy together, share tables, and call each other synchronously in chains → merge them, or cut the coupling for real.
5. Shared database integration — two writers, one table → one writer per fact; integrate through interfaces or events.
6. Casual one-way doors — irreversible choices (public API shapes, ID formats, event schemas) made in passing → mark them, decide them deliberately, version them.
7. Infinite generality — building the platform instead of the product → the second concrete use case earns the abstraction, same as in code.
8. Missing numbers — "high scale", "low latency", "very reliable" → numbers or labeled assumptions; adjectives don't size systems.
9. Big-bang migration — the plan where value arrives only at the end → strangler steps, each shippable, reversible early.
10. Ivory-tower handoff — architecture delivered as diagrams without the first two weeks of work defined → the migration path is part of the design.

Exemplars

Read references/exemplars-architecture.md to calibrate — a greenfield sizing, a real ADR against an empty one, and a migration plan, each shown mid and fable side by side.