Production Design: Topology, Concerns, Shard Key, Index Budget, Backups, Security, Monitoring, and Cost

Learning objectives

1. Start with invariants, not products

2. Reference production architecture

A plausible AtlasMart self-managed design is a three-member replica set per shard, a three-member config-server replica set, multiple mongos routers behind application infrastructure, authenticated/TLS traffic, tenant-aware shard keys, explicit read/write concerns per operation, independent backups, and centralized metrics/logs. The exact node count, regions, hardware, Atlas tier, and shard count are capacity decisions—not curriculum constants.

3. Shard-key and index-budget example

For tenant-dominated access, a compound key such as {tenantId:1, orderId:"hashed"} can preserve tenant targeting while distributing writes inside a tenant, but it is not universally correct: cross-tenant analytics may broadcast, zones may require different key structure, and very large tenants can still dominate workload. Evaluate candidate keys with the Chapter 17 evidence loop rather than copying the example.

from dataclasses import dataclass@dataclassclass Assumptions:    docs:int=20_000_000    avg_doc_bytes:int=1800    secondary_index_bytes_per_doc:int=420    secondary_index_count:int=5    growth_per_month:float=.12a=Assumptions()data=a.docs*a.avg_doc_bytesindexes=a.docs*a.secondary_index_bytes_per_doc*a.secondary_index_countprint("logical data GiB",round(data/2**30,1))print("estimated secondary-index GiB",round(indexes/2**30,1))print("next-month logical multiplier",1+a.growth_per_month)print("MODEL ONLY: replace with measured compression/index/cache/replication/backup factors")

4. Deliberately wrong: architecture by feature checklist

“Replica set + sharding + Search + encryption + ten indexes + five retries” is not an architecture. More features can increase failure modes, write amplification, cost, and operational skill requirements. The repair is traceability: each component must serve an invariant or measured bottleneck, have an owner, have observability, and have a rollback/recovery story.

5. Production acceptance checklist

• Driver compatibility and timeout/retry policy tested against the pinned server line.
• Major query shapes have executionStats evidence and index ownership.
• Read/write concerns map to named business invariants.
• Replica/shard failure drills and application recovery are measured.
• Backup is proven by restore, including encryption/KMS dependencies.
• Least privilege, TLS, network exposure, secret rotation, and audit/log handling are verified.
• Capacity headroom and growth assumptions are recorded.
• SLO alerts link to evidence-first incident runbooks.

6. Production judgment

The production design is a set of defended tradeoffs, not a reference diagram copied into every company. Keep the decision record tied to workload evidence and recovery/security ownership. Lesson 5 turns this design into the final acceptance exercise: build it, load it, fail it, recover it, secure it, tune it, and defend the result.

Authoritative references

Driver defaults and deployment behavior evolve. Re-check the exact server patch, PyMongo release, topology, and managed-service tier before freezing production assumptions.

• PyMongo driver documentation
• Connect to MongoDB with PyMongo
• PyMongo connection pools
• PyMongo client-side operation timeout
• PyMongo monitoring
• PyMongo CRUD configuration / retries
• PyMongo transactions
• PyMongo bulk writes
• PyMongo release notes
• MongoDB connection strings
• Connection string options
• Retryable writes
• Retryable reads
• Transactions
• Change streams
• cursor.skip() and range pagination
• Explain results
• Read concern
• Write concern
• Read preference
• Replica sets
• Sharding
• Choose a shard key
• Security checklist
• Backup methods
• serverStatus
• MongoDB 8.3 release notes
• mongosh changelog