Present the Architecture with Measured Cost / Latency, Data-Governance Controls, Known Limits, and Criteria for Choosing Another Database

1. Architecture review: the deliverable is evidence plus limits

The final AtlasMart artifact is not a diagram labeled “serverless, secure, scalable.” It is a decision package that another engineer can challenge: journeys, data contracts, query/index contracts, trust boundaries, SLO evidence, cost assumptions, recovery drill, deployment rollback, governance inventory and a list of conditions under which Firestore is no longer the right primary store.

2. Final architecture at a glance

3. Evidence register: do not mix proof scopes

4. Measured cost and latency must carry assumptions

{  "reviewDate": "2026-09-17",  "architecture": "Standard Native Core",  "localLoad": {    "dataset": "synthetic AtlasMart",    "concurrency": 32,    "p50Ms": "<record test output>",    "p95Ms": "<record test output>",    "p99Ms": "<record test output>",    "meaning": "local regression only, not production capacity"  },  "costModel": {    "regionExample": "us-central1",    "trafficScenarios": ["best", "base", "worst"],    "priceSourceDate": "2026-09-17",    "pricesAreReplaceableInputs": true  },  "managedEvidence": {    "indexReadiness": "VERIFY_MANAGED",    "queryExplainInsights": "VERIFY_MANAGED",    "billingQuotaMetrics": "VERIFY_MANAGED",    "backupPitrRestore": "VERIFY_MANAGED",    "regionalP95P99": "VERIFY_MANAGED"  }}

Do not fabricate numbers in a production review. Replace placeholders only with captured test output. A forecast without workload distribution, region, retry/listener rates, index behavior and source date is false precision.

5. Governance control matrix

6. Known-limit register

7. Vendor dependency register

8. When another database may be the better primary system

This is not a ranking of databases. It is an exit-criteria register: specific workload properties that would trigger a new architecture evaluation.

9. Wrong final presentation: hide unknowns

The correct final review preserves uncertainty. A release can be approved only when the organization decides which managed gates are mandatory for its risk level and captures them. Unknown is a valid state; pretending it is pass is not.

10. Final mandatory capstone run

1. From a clean clone, run firebase emulators:exec --project demo-atlasmart-firestore --only auth,firestore "npm test".
2. Verify six journey contracts, Rules deny matrix, checkout contention/idempotency, offline cart/reconnect and order-listener lifecycle.
3. Run local distribution benchmark and save p50/p95/p99/error JSON with environment metadata.
4. Run aggregation/materialized-summary reconciliation and optional deterministic vector relevance harness.
5. Execute local recovery drill and save RPO/RTO/count/hash/config evidence.
6. Exercise schema/deploy canary rollback criteria from Chapter 26.
7. Generate cost scenarios and confirm price/source date is separate from billable-unit assumptions.
8. Produce architecture-review.md containing ADR, evidence register, governance matrix, known limits, vendor dependencies, managed verification gates and exit criteria.

11. Course completion judgment

A production Firestore system is not “serverless, therefore effortless.” The application still owns data modeling, authorization intent, query/index design, client cache UX, transaction/idempotency boundaries, hotspot distribution, lifecycle policy, observability, cost assumptions, deployment compatibility and recovery drills. Firestore removes infrastructure classes of work; it does not remove architecture.

The capstone’s final skill is not memorizing an SDK. It is deciding which Firestore mechanism belongs on a request path, proving what that mechanism actually guarantees, measuring its consequences, and knowing when the workload has crossed the boundary where another system deserves evaluation.

Knowledge check

1. Why are VERIFY_MANAGED items valuable rather than embarrassing?
2. What is the strongest reason the capstone chooses Standard Native Core?
3. Which evidence should never be inferred from the emulator?
4. Why is an exit-criteria register part of good architecture?
5. What is the final distinction between a Firestore feature list and an operable Firestore system?

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.