Microservices and Full Offline Studio Awareness

Two architecture jumps, two independent problems

Imagine a small team maintaining a reasonably modular monolith and a browser-based content studio. Leadership proposes two changes as signs of architectural maturity: split the system into Microservices and build a Full Offline Studio. The proposal sounds coherent, but the two choices solve different pressures and neither becomes the default merely because the product is growing.

For Microservices, start with service-decomposition pressure: are there autonomous teams with clear domain boundaries? Is independent release, independent scaling, or failure isolation actually required? Can the distributed-transaction and operational obligations be owned? The Microsoft Azure Architecture Center describes microservices as small autonomous services aligned with business capabilities and bounded contexts, while also discussing independent deployment/scaling and distributed-system operational challenges. That FACT does not itself authorize adoption in MAKNOW. [MSMICRO]

For a Full Offline Studio, evaluate a separate requirement: how long must users remain disconnected? Are local writes merely cached drafts or authoritative edits? What are the synchronization, conflict, update, recovery, and security policies? Service Workers can intercept fetches and support offline-enabled web experiences, and IndexedDB provides persistent structured client-side storage; those mechanisms do not by themselves constitute a complete offline studio with synchronization, conflict, and recovery guarantees. [SW] [IDB]

The lesson artifact is Architecture Complexity Trigger and Offline-Studio Decision Record v1. It contains two independent records: MICROSERVICES and FULL_OFFLINE_STUDIO. Allowed states are USE, PILOT, NOT_NOW, UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, HOLD, PARTIAL, and DISPUTED. Missing decisive evidence never becomes a success state, while a measured absent trigger can legitimately produce NOT_NOW.

Planned active time: 45 minutes.

This lesson is for a learner who must make architecture complexity auditable before adoption: trigger, simpler alternative, owner, migration cost, failure surface, and revisit evidence.

This lesson does not deploy or migrate production microservices or a production offline studio, and it does not absorb the adjacent Elasticsearch/OpenSearch/GraphQL or Native/Billing/Tenancy outcomes.

HARD prerequisite — AWR-001

Before the Fast Path, state the relevant AWR-001 boundary in one sentence: why is a technology name or its modernity not an adoption trigger? Then distinguish problem, measured trigger, simpler alternative, and accountable owner/cost. If you cannot separate those four elements, the Fast Path is not open.

Bounded bridge: recover only this evidence rule: “technology name is not adoption evidence; a specific problem, observable trigger, simpler alternative, owner, and cost/failure boundary must be visible, and NOT_NOW can be correct.” The bridge does not fabricate or complete the prior outcome.

SOFT prerequisite — AWR-003

If you completed AWR-003, recall its overlap boundary: a search/API capability does not automatically authorize the next architecture adoption. Fragility here does not block entry, but it increases the risk of absorbing adjacent outcomes.

Optional bridge: carry forward only the overlap boundary. Do not import Elasticsearch/OpenSearch or GraphQL technology-fit outcomes into the Microservices or Full Offline Studio decision.

Diagnose the pressure before choosing the architecture

Four quick checks:

1. The codebase is larger, but one main team still owns one release train and domain boundaries remain vague. Does code size alone justify Microservices?
2. Several domains have independent owners, independent release pressure, and an explicit failure-isolation need. Can that evidence change only the Microservices record?
3. A Service Worker supports cached reads, but authoritative offline writes and synchronization are not required. Is that a Full Offline Studio?
4. Field users must work disconnected for a full shift and create authoritative local edits. Can a success state be justified without a conflict policy?

4/4 → Fast Path. 2–3 → Repair Path. 0–1 → Foundation Path. The Fast Path compresses definitions; it does not remove negative evidence, ownership/cost, distributed or local-state obligations, or transfer.

Self-check: do not treat codebase size as team autonomy, a Service Worker as an offline product architecture, local storage as conflict policy, or “maturity” as evidence.

Mental model: two evidence chains

MICROSERVICES → problem class → team/domain evidence → independent deploy/scale/failure-isolation pressure → distributed consistency/operations burden → simpler modular-monolith alternative → owner + migration/failure surface → bounded state

FULL_OFFLINE_STUDIO → disconnected-duration requirement → authoritative local writes → sync + conflict policy → update/recovery/security → simpler online-first/offline-capable mode → owner + migration/failure surface → bounded state

The two chains do not score each other. Microservices can be PILOT while Full Offline Studio is NOT_NOW, or the reverse. The state must come from the evidence of its own axis.

Keep three authority layers separate: external FACT describes mechanisms and capabilities; local evidence records the problem and constraints; MAKNOW DESIGN defines the state vocabulary and acceptance gates. [MSMICRO], [SW], and [IDB] support FACT boundaries; MAKNOW design controls trigger gates and use/not-now semantics.

If the diagram cannot render, this ordered text is a complete equivalent of asset://AWR-004/AWR-004-ASSET-FLOW.

Evidence contract for each axis

MICROSERVICES

Name the problem_class precisely, then keep team_count separate from bounded_context_evidence. Team count without stable domain ownership is not enough. Record independent_deploy_need, independent_scale_need, and failure_isolation_need independently. distributed_transaction_risk and operational_maturity expose adoption cost and risk. A simpler_alternative must be considered; for many pressures a stronger modular monolith remains the simpler candidate. The Microsoft overview explains bounded contexts and independent deployment/scaling, but it is not adoption authority. [MSMICRO]

FULL_OFFLINE_STUDIO

Separate offline_duration_requirement from a vague claim that “the network is sometimes weak.” Record local_data_volume separately so storage/working-set scope is visible rather than implied. offline_write_requirement must say whether local edits are authoritative or whether the need is only cache/read. Authoritative writing makes sync_requirement, conflict_policy, update_strategy, recovery_strategy, and security_boundary decisive. Service Worker and IndexedDB are browser mechanisms, not a complete synchronization and recovery policy. [SW] [IDB]

For both records keep operational_owner, migration_cost, failure_surface, chapter_exit_evidence, review_due, rationale, and stop_or_pivot_trigger. authority_refs must make FACT and DESIGN traceable.

Building Architecture Complexity Trigger and Offline-Studio Decision Record v1

Step 1: create two independent records. A shared “architecture maturity” score is not allowed.

Step 2: separate Microservices pressure from superficial symptoms. Codebase size, repository count, or endpoint count are not defined by this contract as adoption triggers. Evidence must connect to autonomous team/domain boundaries and independent release, scale, or failure-isolation pressure. If bounded-context evidence or deploy pressure is unresolved, stop the success path.

Step 3: make distributed cost visible. Microservices can add communication, observability, consistency, and operational obligations, so distributed_transaction_risk and operational_maturity belong in the decision. [MSMICRO]

Step 4: separate a Full Offline requirement from an offline-capable feature. Cache, read-only snapshots, or bounded local drafts can be smaller alternatives. A Full Offline Studio becomes a different product architecture when disconnected duration and authoritative local writes are real requirements and synchronization, conflict, update, recovery, and security policies are defensible. [SW] [IDB]

Step 5: test the simpler alternative. For Microservices, test a stronger modular monolith with clearer boundaries. For Offline, test an online-first mode with cache/read or bounded local drafts. Reject the alternative only when evidence shows that it cannot meet the requirement.

Step 6: name ownership and failure surface before the state. Microservices without an accountable operations owner, or Full Offline without a data/synchronization owner, cannot produce a positive state. Migration cost and rollback/recovery paths must be visible before accepting complexity.

Step 7: derive the state from the evidence. USE and PILOT are success states and require a measured trigger plus owner and cost/failure evidence. NOT_NOW is valid only when the trigger of that axis is measured absent and a simpler alternative serves the need. Missing decisive evidence stays typed uncertainty.

Worked example: split the proposal into two records

A product studio runs a modular monolith and a browser editor. Architecture says, “the codebase is large, so we need Microservices,” while product says, “we already have a Service Worker, so we should become fully offline.” Convert both shortcuts into evidence.

For Microservices ask: how many teams are actually autonomous? Are bounded contexts stable and owned? Is independent deployment, scale, or failure isolation required? If those answers are unresolved, code size remains a symptom rather than a proven trigger. Keep a stronger modular monolith as the simpler alternative.

For Offline ask: what disconnected duration is required? Must users create authoritative local edits? If not, and cached/read-only behavior covers short outages, Service Worker/IndexedDB capability does not prove a Full Offline trigger. If authoritative writes are required, a decision without conflict, update, and recovery policies is still incomplete. [SW] [IDB]

The table asset://AWR-004/AWR-004-ASSET-TABLE must let a reviewer reconstruct each state from row evidence. This worked example is not a fixture answer key; shipped lab templates contain no prefilled decision.

Common failure modes

1. Codebase-size fallacy: treating repository growth as autonomous-domain pressure. Repair by measuring team/domain/release evidence separately.
2. Service Worker = Full Offline: treating fetch interception or cache as authoritative offline editing. Repair by exposing write, sync, conflict, update/recovery, and security evidence. [SW] [IDB]
3. Missing owner → success: no operations or data/sync owner exists, yet the record says PILOT. Preserve OWNER_MISSING or another typed non-success state.
4. Unknown → NOT_NOW: decisive evidence is unresolved, but the record uses NOT_NOW for convenience. NOT_NOW requires measured absence; unknown remains unknown.
5. Adjacent scope absorption: pulling search/API or Native/Billing/Tenancy outcomes into this lesson. Restore the V13/C01 owned boundary.
6. Vendor fact → MAKNOW authority: treating capability documentation as an adoption verdict. Separate FACT and DESIGN in authority refs.

Experienced bridge: compress definitions, not evidence

If you already know microservices and offline architecture, shorten introductory definitions but keep five questions:

• What is the exact pressure on this axis and how is it measured?
• Where does the simpler architecture actually fail?
• Who owns the added failure surface?
• Which evidence is FACT and which rule is MAKNOW DESIGN?
• What will stop, pivot, or reopen the decision?

The Experienced Path does not lower the evidence bar. Trade-off defense, a negative case, provenance, and changed-context transfer remain auditable.

Compare alternatives before the complexity jump

Modular monolith versus Microservices

If the actual problem is boundary clarity, a modular monolith with clearer module ownership and interfaces may remain the simpler option. Microservices become more defensible when autonomous domains/teams and independent release, scale, or failure-isolation pressure are real and the distributed operational cost is accepted. [MSMICRO]

Offline-capable versus Full Offline Studio

If the need is limited to short outages, cached reads, or bounded local drafts, an online-first/offline-capable mode may be enough. Full Offline Studio carries more obligations: authoritative local writes, synchronization, conflict policy, update/recovery, and security. Service Worker and IndexedDB can be pieces of the mechanism without proving the product decision. [SW] [IDB]

Do not reduce the trade-off to “which technology is better?” Ask which architecture introduces the least complexity necessary for the proven requirement while retaining accountable ownership and recovery.

Guided and independent practice

Run the offline lab at lab://AWR-004/AWR-004-LAB1. All fixtures are synthetic and read-only. The learner starter exposes structure and rule vocabulary but contains no pre-solved verdict.

Guided pass:

1. Choose one shipped fixture.
2. Build MICROSERVICES and FULL_OFFLINE_STUDIO records from exact evidence.
3. Write your own rationale, review_due, and stop_or_pivot_trigger.
4. Run the checker and map each failed rule back to a specific field.

Independent pass: analyze the codebase-size, offline-without-conflict, service-worker-cache-only, owner-missing, and missing-evidence mutations without copying the baseline. The goal is not to discover a hidden answer; it is to keep the state consistent with visible evidence.

The Fast Path may jump here only after the HARD AWR-001 boundary is stable. AWR-003 is SOFT context and must not absorb adjacent outcomes.

What makes the evidence package acceptable?

For each axis the artifact must expose problem class, measured trigger fields, simpler alternative, operations/data owner, migration cost, failure surface, decision state, chapter-exit evidence, review due, and a stop/pivot trigger. For Microservices the decisive fields include team/domain/deploy/scale/failure-isolation pressure and distributed risk. For Offline they include duration, local_data_volume, writes, synchronization, conflict, update, recovery, and security. Each row also carries its explicit problem and learner rationale.

authority_refs are part of the evidence package: Microservices FACT traces to MSMICRO and AWR-004-K1; browser offline mechanisms trace to SW/IDB and AWR-004-K2; the Full Offline definition and adoption gates trace to DESIGN claims AWR-004-K3 and AWR-004-K4.

The checker validates exact fixture binding and visible consistency rules only. A human rationale must still explain why the state is no stronger than the evidence. AI may organize supplied evidence but may not invent an owner or measured trigger.

Assessment and transfer

AWR-004-F1: retrieve the owned boundary and one adjacent non-goal.

AWR-004-F2: diagnose the mutation “increase codebase size without adding independent teams, deploy pressure, or bounded-context evidence” and identify the invalid field/state plus minimum repair.

AWR-004-F3: recompute the changed context instead of copying the baseline.

AWR-004-S1: explain the boundary and one non-goal.

AWR-004-S2: build Architecture Complexity Trigger and Offline-Studio Decision Record v1 from the baseline synthetic fixture.

AWR-004-S3: diagnose the codebase-size shortcut.

AWR-004-S4: a second product grows to several autonomous teams with clearly bounded domains and independent release pressure, while field users must work disconnected for an entire shift and create authoritative local edits. Recompute both decisions independently and defend owner, alternative, migration/failure surface, and review trigger for each.

Transfer passes only when the changed context changes the relevant evidence of each axis. “Both architectures are mature now” is not an acceptable argument.

Sources and freshness boundary

MSMICRO — Microsoft Azure Architecture Center, official Microservices overview covering bounded contexts, autonomous services, independent deployment/scaling, and operational challenges. [MSMICRO]

SW — W3C Service Workers specification, covering fetch interception and mechanisms for offline-enabled web applications. [SW]

IDB — W3C IndexedDB specification family, covering persistent structured client-side storage. [IDB]

These sources were recorded for the lesson claim boundaries on 2026-09-03; the next review is due 2026-12-02. They support mechanism/capability FACT. Trigger thresholds, the state vocabulary, and MAKNOW adoption gates remain DESIGN authority. If source semantics materially change before the review date, the affected claim must be rechecked. This lesson does not expand the claim scope beyond those boundaries.