Reference Architecture Worked Solutions
Why this page matters
Blueprints become useful when they produce artifacts. This page gives compact worked solution packs for each reference architecture.
| Artifact | Example |
|---|
| route matrix | login SSR/no-store; dashboard server shell plus client panels; orders client-heavy table |
| data ownership | tenant/role from session; filters in URL; server data through BFF/query cache |
| ADR | choose modular monolith before microfrontends until independent deploy pressure is proven |
| risk register | authorization drift, table INP, export failures, cross-feature imports |
| rollout | feature flags by route, beta tenants, route Web Vitals and mutation error dashboard |
| Artifact | Example |
|---|
| route matrix | homepage/listing static or cached; product cached with revalidation; cart/checkout dynamic |
| data ownership | catalog cacheable; cart server/session-owned; payment provider isolated |
| ADR | third-party scripts delayed and governed by owner/purpose/data class |
| risk register | stale price, inventory mismatch, tag latency, checkout script failure |
| rollout | variant canaries, cache purge plan, checkout kill switches |
| Artifact | Example |
|---|
| package map | tokens -> themes -> primitives -> components -> product apps |
| data ownership | API/version ownership in platform; adoption metrics from consuming apps |
| ADR | semantic tokens become public contract; primitive values stay internal |
| risk register | forks, inaccessible primitives, breaking changes, brand leakage |
| rollout | migration guide, deprecation window, codemods, adoption scorecard |
| Artifact | Example |
|---|
| boundary map | shell owns auth/nav/observability; domain apps own routes and data |
| data ownership | no shared mutable client store across microfrontends |
| ADR | adopt microfrontends only for independently shipped bounded contexts |
| risk register | duplicate runtimes, contract drift, shell monolith, cross-app coupling |
| rollout | one pilot domain, compatibility matrix, runtime budget gate |
| Artifact | Example |
|---|
| boundary map | deterministic shell, orchestrator, registry, tool gateway, RAG, evals |
| data ownership | retrieved sources cited; tool output authoritative only after server policy |
| ADR | model selects approved schemas, never arbitrary executable UI |
| risk register | prompt injection, unsafe tool call, stale retrieval, inaccessible generated UI |
| rollout | internal canary, eval gate, kill switch by tool class, audit dashboard |
| Artifact | Example |
|---|
| data map | local DB for assigned work; server remains authoritative after sync |
| mutation model | durable queue with idempotency key and visible sync state |
| ADR | conflict policy is per domain object, not global last-write-wins |
| risk register | data loss, hidden conflict, sensitive storage, stale permissions |
| rollout | field pilot, queue-age dashboard, conflict review, emergency export path |
| Artifact | Example |
|---|
| route matrix | static/cached landing; hydrated lead form island; dynamic submission API |
| data ownership | campaign/variant assignment at edge; lead form validated server-side |
| ADR | experiments cannot bypass route budget or script governance |
| risk register | LCP regression, attribution mismatch, cache leak, form timeout |
| rollout | variant-level RUM, script kill switches, conversion plus Web Vitals dashboard |
- Does each solution include route/data decisions?
- Is there at least one ADR-worthy tradeoff?
- Is rollout tied to measurable production signals?
- Are risks written with owners and mitigations?
- Pick one worked solution and expand it into a full capstone packet.
- Write the ADR for one rejected alternative.
- Create a risk register with owner, severity, mitigation, and review date.
Use these worked solutions with the reference architecture blueprints, capstone solution packs, and Part XII review artifacts.