audit-backend-architecture — Distributed-Systems Pattern Maturity Audit

Degree of freedom: MIXED — Fit, presence, and adopt/defer [HIGH freedom]; Phase 0 topology probes [LOW freedom — run exactly]. Never mark a pattern Missing if its tier is N/A.

Read-only. Assess and recommend; do not change code. Per-call timeouts, retry+jitter, idempotency keys, cancellation → audit-resilience. This skill checks whether the patterns exist and whether they fit.

Two lenses:

1. Conformance (Phase 2) — Implemented / Partial / Missing / N/A with file:line.
2. Fit / decision (Phase 3) — Adopt now / Adopt when [trigger] / Defer (premature). "Don't build this yet" is a first-class finding.

Core principle — start simple, earn every pattern

Each pattern solves a specific problem and carries a specific cost. The current consensus is modular-monolith-first: >90% of systems are well served by a well-structured monolith; premature decomposition is the #1 failure mode. A pattern is "Missing" only if the measurable trigger is present — otherwise adopting it is over-engineering, flagged as loudly as a real gap.

• Fit beats presence. "No service mesh / no CQRS" is a finding only when a trigger is present.
• Decide per interaction, not per system. Sync vs event-driven is chosen per boundary-crossing call (see references/patterns.md → Communication style).
• Distributed monolith is worse than a monolith. Shared DB + coupled deploys pays the distributed tax with none of the independence.
• Reversible steps. Prefer modular monolith, façade, outbox over premature service split or event-sourcing everywhere.

How to reason — Observe → Interpret → Classify → Severity

1. Observe — topology signals + the file:line (or "searched, none found")
2. Interpret — is there a present pain, a named future trigger, or no trigger?
3. Classify — Implemented / Partial / Missing / N/A, then Adopt now / Adopt when / Defer
4. Severity — dual-write, cascade-outage, silent inconsistency = Critical; Missing with no trigger = over-engineering, not a gap

Worked example

Observe: T1 Next.js + Supabase. orders/service.ts writes the row then publishes to a queue in a second step. Product page hits the DB on every request. No k8s, mesh, or multi-service fleet. Interpret: a crash between write and publish loses the fulfillment event (dual-write). Hot reads have no cache. Mesh and CQRS have no trigger. Classify: Outbox = Adopt now; cache-aside = Adopt now; mesh / CQRS = Defer (T1 N/A). Severity: Critical for dual-write; High for the uncached hot path. Finding: Outbox (#6) | orders/service.ts | Critical | Adopt now — close dual-write. Mesh | N/A (T1) | Defer — no 10+ service fleet.

Phase 0 — Detect topology (gates every later finding) [LOW freedom — run exactly]

Architecture advice is only correct in context. Flagging "no service mesh" on a Next.js + Supabase app is noise; missing it on a 40-service Kubernetes fleet is critical. Classify the repo first, then apply only the patterns that fit. Never report a pattern as "Missing" if its topology tier is N/A.

# Deploy target / runtime
rg -n --hidden -g '!node_modules' -l "vercel\.json|netlify\.toml|next\.config|supabase/config" # serverless/PaaS
fd -H -t f 'Dockerfile|docker-compose\.ya?ml|Containerfile'                                     # containers
fd -H -t d 'k8s|kustomize|charts|helm' ; rg -n "apiVersion:\s*(apps|networking)" -g '*.{yaml,yml}' -l # kubernetes
# Service count / boundaries
fd -H -t f 'package.json|go.mod|pyproject.toml|pom.xml|Cargo.toml' | rg -v node_modules         # count deployable units
# Messaging / eventing
rg -n "kafka|rabbitmq|amqp|nats|sqs|sns|pubsub|kinesis|redpanda|temporal|inngest|trigger\.dev" -l
# Inter-service transport
rg -n "grpc|@grpc|protobuf|\.proto|graphql|apollo|federation|trpc" -l
# Mesh / gateway infra
rg -n "istio|linkerd|consul|envoy|kong|apisix|traefik|nginx-ingress|api-?gateway|ztunnel|waypoint" -l

Record a topology profile and pick the tier:

If there are no backend services (static site / pure frontend), stop and report reduced applicability — hand any API-client concerns to audit-fe-api.

Phase 1 — Research current patterns [HIGH freedom]

Follow /research: confirm current-year conventions and the installed libraries for the detected stack (gateway/proxy, breaker/bulkhead libs, outbox/CDC tooling, saga/workflow engines, mesh mode). Anchor recommendations to versions actually in the manifest — never propose a library the repo can't run.

Phase 2 — Architecture maturity matrix [HIGH freedom]

For each in-scope pattern, mark Implemented / Partial / Missing / N/A with file:line, a one-line "why it matters", and the fix-delegate. Detailed detection commands, "good vs. red-flag" signals, and fix targets for every pattern are in references/patterns.md — load it and work through the applicable rows.

Communication & data-flow choices (decide per interaction, not per system)

These are selection decisions, not "missing features" — the answer depends on each interaction and the stage. Detection + trade-offs in references/patterns.md.

Rules:

• Evidence or it didn't happen — every verdict cites file:line or "searched, none found".
• N/A is a first-class verdict — record why (topology tier), don't silently drop a row.
• Don't double-count audit-resilience's per-call concerns; link to it instead.

Phase 3 — Decide: fit, not just presence [HIGH freedom]

A pattern being "Missing" is only actionable if the codebase has the trigger that justifies it. For every candidate pattern, classify it into one of three buckets from the detected symptoms:

• Adopt now — a real, present pain maps to this pattern (evidence: file:line + the symptom).
• Adopt when [trigger] — not yet, but name the concrete signal that should flip it on.
• Defer (premature) — no trigger present; adopting now is over-engineering. Say so plainly.

Maturity ladder (climb only when the rung's trigger fires)

Symptom → pattern (the decision table)

Over-engineering guardrails (flag these as findings too):

• CQRS / event sourcing where reads and writes don't actually diverge → remove complexity.
• Microservices / mesh / cell-based below the size + differential-scaling threshold → stay modular monolith.
• Wholesale event-driven for simple two-party interactions → a single durable queue (or a sync call) is enough.
• A split that produces a distributed monolith (shared DB, coupled deploys) → worse than the monolith.

Phase 4 — Prioritized report + decision (read-only) [HIGH freedom]

## Backend Architecture Audit — [repo] — [date]
**Topology:** [tier + evidence: N services · broker? · k8s? · transport]
**Stage on the ladder:** [0–4]  ·  **In scope:** [patterns]  ·  **N/A (out of tier):** [list + why]

### Adopt now (present pain → pattern, with evidence)
| Pattern | Symptom (file:line) | Payoff | Fix via |
|---|---|---|---|
| Cache-aside | product page: 100ms DB read per request, no cache (api/products.ts:40) | ~10ms cached reads, DB load ↓ | backend-patterns |

### Adopt when (named trigger, not yet)
| Pattern | Trigger to watch for |
|---|---|
| Database-per-service | orders + billing need independent deploy cadence / separate teams |

### Defer — would be over-engineering now
| Pattern | Why premature |
|---|---|
| CQRS / event sourcing | reads and writes don't diverge; a repository is simpler |
| Service mesh / cell-based | single modular deploy; no 10+-service fleet |

### Critical (data loss / cascading outage / silent inconsistency)
| Gap | Pattern | file:line | Why it bites in prod | Fix via |
|---|---|---|---|---|
| Payment writes DB then publishes to Kafka separately | Outbox (#6) | orders/service.ts:88 | Dual-write: crash between = paid order, no fulfillment event | backend-patterns |
| No breaker/bulkhead around payment provider | #3/#4 | ... | One slow provider exhausts the pool → whole API 503s | audit-resilience/backend-patterns |

### High / Medium (maturity matrix)
| Pattern | Implemented | Partial | Missing | N/A | Fix via |
|---|---|---|---|---|---|
| API gateway | ... | ... | ... | | backend-patterns |
| BFF / composition | ... | ... | ... | | design-api |
| Hexagonal | ... | ... | ... | | workflow-refactor |

### Lift-to-production roadmap (ordered)
1. Close dual-write with Outbox (+ idempotent consumers) → backend-patterns
2. Breaker + bulkhead on every external dependency → audit-resilience → backend-patterns
3. Centralize gateway concerns (auth/rate-limit/CORS/logging) → backend-patterns / audit-security
4. Distributed tracing + SLOs before scaling → backend-observability
5. [T3] Adopt ambient mesh for mTLS/L7 instead of hand-rolled retries → backend-patterns

Forbidden: declaring "production-grade" from passing tests alone; flagging T3-only patterns (mesh, cell-based, CQRS) against a T1 monolith; re-auditing per-call timeouts/retries that audit-resilience owns; recommending a saga without compensation logic; recommending CQRS/event sourcing where read and write loads don't actually diverge; recommending any pattern without naming its trigger (fit before presence — a "Missing" with no trigger is over-engineering, not a gap); recommending a service split that yields a distributed monolith (shared DB + coupled deploys).

Self-critique before reporting [LOW freedom — do not skip]

1. Evidenced — file:line or "searched, none found", not "they probably need a mesh"
2. Tier respected — T3-only rows are N/A on T1, with why
3. Trigger named — every Adopt now / Adopt when / Defer cites a symptom or its absence
4. Right owner — per-call timeout/retry → audit-resilience; mechanical layer rules → enhance-arch-boundaries
5. Nothing changed until approved

Related

• audit-resilience — per-call runtime resilience (timeouts, retry+backoff+jitter, idempotency keys, cancellation, PII); this audit defers those to it
• backend-patterns — implement the architecture: gateway, BFF, outbox, saga, bulkhead, hexagonal (see its references/architecture-patterns.md)
• design-api — API contract, versioning, error shapes, pagination
• audit-security — auth, CORS, rate-limit-as-abuse-control, mTLS/zero-trust, injection
• backend-observability — tracing, correlation IDs, RED/USE metrics, SLOs, PII redaction
• audit-db-schema — the data-model side of CQRS / event sourcing / outbox tables / db-per-service
• backend-db-performance — cache-aside, query optimization, read replicas for hot paths
• workflow-refactor — hexagonal restructure and strangler-fig migration; modular-monolith boundaries
• complete-everything — close the audited gaps to done with verification