Define User Journeys, Data Model, Queries, Realtime / Offline Needs, Atomicity, Retention, Security, SLOs, and Cost Budget

1. AtlasMart capstone brief: choose a system before choosing features

The final chapter starts with a deliberately ordinary product requirement: AtlasMart needs public product browsing, a private cart, checkout with inventory protection, live order status, limited offline usefulness, operational analytics, retention, recovery, and predictable cost. That sounds like “use every Firestore feature from the course.” It is not. The architecture review must prove why each mechanism exists, what state it protects, and which requirement would make the team remove or replace it.

The first decision is deliberately conservative: Standard edition, Native mode, Core operations. It already provides the client-side realtime/offline model, Security Rules path, server SDKs, transactions, indexes and managed scale needed by this slice. Enterprise Pipeline, MongoDB compatibility and vector retrieval are not architectural badges; they are conditional tools evaluated later against measurable needs.

2. Define the terms before the architecture diagram

3. User journeys become database contracts

4. Architecture decision record: choose Standard Core deliberately

{  "decision": "Standard Native Core for AtlasMart transactional application slice",  "date": "2026-09-17",  "database": {"id":"(default)","edition":"STANDARD","mode":"NATIVE"},  "requirements": {    "mobileWebRules": true,    "realtimeOrderStatus": true,    "offlineCart": true,    "trustedCheckout": true,    "advancedPipelineJoinRequired": false,    "mongodbDriverDependency": false,    "semanticSearchRequiredAtLaunch": false  },  "managedProofStillRequired": [    "composite index readiness",    "production p95/p99 and contention",    "IAM/App Check enforcement",    "billing and quota telemetry",    "backup/PITR recovery drill"  ],  "revisitWhen": [    "Pipeline-only query materially reduces application complexity/cost",    "MongoDB compatibility becomes a migration constraint",    "measured Standard economics or query limits fail the workload"  ]}

5. SLOs: define population, threshold and evidence

“Fast” and “highly available” are not testable. AtlasMart writes explicit targets, then labels which are local engineering targets versus managed production SLO evidence. Emulator latency is useful for regression inside one machine; it is not a regional service-latency forecast.

6. Data model from access patterns

products/{productId}  tenantId, categoryId, name, active, visibility, priceCents,  inventorySkuId, updatedAt, schemaVersioncarts/{uid}  ownerUid, currency, updatedAt, schemaVersioncarts/{uid}/items/{productId}  ownerUid, productId, quantity, observedPriceCents, updatedAtinventory/{skuId}  available, reserved, version, updatedAtorders/{orderId}  ownerUid, idempotencyKey, status, lineItems[], totalCents,  createdAt, updatedAt, schemaVersionevents/{eventId}  type, subjectId, occurredAt, expireAt, legalHold, schemaVersion

7. Wrong approach: feature checklist architecture

The repair is a requirement-to-mechanism ledger. A feature is accepted only if its requirement, owner, test, cost surface, fallback and exit criterion are written down. Optional capabilities can still be taught—but they remain optional until the evidence changes the decision.

8. Mandatory local lab: architecture contract before code

1. Create capstone/adr.json from the decision record above.
2. Create capstone/journeys.json with the six journeys and expected query/write/security path.
3. Create capstone/known-limits.json with emulator index/limit/transaction gaps, transaction retry semantics, hotspot risk, TTL eventuality, vector no-listener boundary and recovery cloud-only evidence.
4. Start Firestore/Auth emulators under demo-atlasmart-firestore.
5. Seed five products, one cart, two inventory SKUs, one order and synthetic events.
6. Run a script that validates every document has schemaVersion and every journey has an evidence owner.

import fs from "node:fs";const adr = JSON.parse(fs.readFileSync("capstone/adr.json", "utf8"));const journeys = JSON.parse(fs.readFileSync("capstone/journeys.json", "utf8"));if (adr.database.edition !== "STANDARD") throw new Error("unexpected edition");for (const j of journeys) {  if (!j.requirement || !j.mechanism || !j.evidence || !j.rollback) {    throw new Error(`incomplete journey contract: ${j.name}`);  }}console.log(`architecture gate: ${journeys.length} journeys complete`);

Production judgment and bridge

Firestore is a fit only if the journeys can be implemented without hiding correctness, security, cost or operability debt. Lesson 2 now turns the contracts into documents, indexes, typed SDK access, Rules, listeners and a trusted checkout path while preserving the client/server trust boundary.

Knowledge check

1. Why is Enterprise not the automatic capstone choice?
2. Which AtlasMart action may work offline, and which must remain online?
3. Why does an SLO need a population and evidence source?
4. Why is App Check absent from the core authorization decision?
5. What should trigger a database-choice review?

Authoritative references

• Firebase: Cloud Firestore documentation — Standard Native/Core application semantics.
• Firebase: Security Rules conditions — Rules are not filters and server libraries bypass Rules in favor of IAM/ADC.
• Firebase: Connect to the Cloud Firestore emulator — demo projects and emulator/production differences.
• Firebase: Transactions and batched writes — retries, atomicity and offline constraints.
• Firebase: Firestore best practices — hotspot avoidance and gradual traffic ramping.
• Firebase: Firestore pricing — document/index-entry/listener/aggregation billing in Standard.
• Firebase: Vector search — vector indexes, dimensions, query limits and supported server SDKs.
• Google Cloud: Firestore release notes — current Enterprise/Pipeline launch status and product changes.
• Google Cloud: Core and Pipeline query interfaces — Standard/Enterprise indexing and query-interface differences.
• Google Cloud: Firestore with MongoDB compatibility overview — serverless compatibility surface, not MongoDB itself.
• Google Cloud: Firestore backups and restore — managed recovery mechanisms.
• Google Cloud: Point-in-time recovery — historical recovery window and managed semantics.