Backups, Upgrades, Observability, Private Networking, and Vendor-Specific Failure Modes

1. Managed operations are a dependency graph, not one SLA

AtlasMart’s database request depends on more than the storage fleet. A typical path is application identity → DNS/service discovery → private network endpoint → provider frontend → database data plane → encryption/key access → replicas/indexes. Management and recovery add control-plane IAM, backup catalogs, restore APIs, quotas, monitoring/event delivery and maintenance/update workflows. A provider can keep the database fleet healthy while AtlasMart’s private DNS points at a retired endpoint or a KMS policy blocks decrypt.

Managed services reduce some low-level operational work, but they also introduce service-specific contracts. Point-in-time recovery (PITR) may restore into a new resource rather than overwrite the damaged one. Private endpoints can require DNS changes when regions/endpoints change. Quotas may gate account-level throughput or control-plane requests. Maintenance can be provider-driven even when customers choose windows or deferrals. The architecture must document these dependencies as carefully as replica count.

2. Treat backup, networking, upgrade, and observability as four acceptance planes

A managed backup should be tested like Chapter 22’s recovery system: restore into isolation, compare counts/checksums/invariants, verify encryption/key access and indexes, then rehearse cutover. “Backup enabled” is configuration state, not recovery evidence.

3. Deliberately wrong approach: bypass a private-network failure by opening the public endpoint

Imagine a provider-side endpoint replacement succeeds but AtlasMart’s private DNS still resolves an old address. The service health dashboard is green, yet application connections fail. Under incident pressure, enabling public access can make the request work while violating segmentation and exposing a new attack surface. The safer correction repairs the private name/path and preserves the deny-by-default boundary.

4. AtlasMart lab: healthy service, broken private path, validated PITR cutover

from dataclasses import dataclass

@dataclass
class ManagedState:
    service_health: str
    private_endpoint_ip: str
    private_dns_ip: str
    public_access: bool
    latest_restore_point: int
    app_client_compatible: bool

state = ManagedState(
    service_health="healthy",
    private_endpoint_ip="10.0.2.9",  # provider-side endpoint replacement/failover
    private_dns_ip="10.0.1.5",      # stale customer DNS mapping
    public_access=False,
    latest_restore_point=420,
    app_client_compatible=True,
)

def connect(s):
    if s.private_dns_ip == s.private_endpoint_ip:
        return "private-connect-ok"
    if s.public_access:
        return "public-fallback-ok"
    return "connection-failed-private-dns-stale"

print("MANAGED SERVICE STATUS:", state.service_health)
print("APPLICATION CONNECTIVITY:", connect(state))
print("wrong emergency fix: enable public access")
state.public_access = True
print("connectivity after unsafe fallback:", connect(state))
print("policy violation: public exposure widened during incident")

# Safe repair: keep public access closed and repair private DNS/service endpoint integration.
state.public_access = False
state.private_dns_ip = state.private_endpoint_ip
print("safe repair:", connect(state))

# PITR is useful only after restore + validation + cutover planning.
requested_restore_point = 417
restored_orders = {"o1": "paid", "o2": "shipped", "o3": "paid"}
expected_orders = {"o1": "paid", "o2": "shipped", "o3": "paid"}
print("\nRESTORE GATE")
print("restore point available=", requested_restore_point <= state.latest_restore_point)
print("isolated restored object count=", len(restored_orders))
print("validation matches=", restored_orders == expected_orders)
print("cutover allowed=", restored_orders == expected_orders and state.app_client_compatible)

5. Production judgment: design for the service-specific failure envelope

Keep a provider/service appendix with quotas, endpoint types, backup retention and restore target behavior, region dependencies, IAM roles, encryption/key dependencies, maintenance/deprecation channels, observability APIs, and known feature limitations. Subscribe to security/release notices and rehearse client upgrades. When a service is fully managed, patch installation may be provider-owned, but reviewing behavior changes and testing the application remains AtlasMart’s responsibility.

Incident drills should distinguish data-plane outage, control-plane outage, private-network/DNS failure, IAM/KMS denial, quota exhaustion, backup restore delay and region dependency. This decomposition prevents the dangerous conclusion that “provider SLA = application availability.” The final lesson adds money and organizational capacity to the same reasoning, including the cost of leaving a managed service later.

References

Provider-specific claims below are current implementation anchors reviewed in August 2026. They are not universal NoSQL definitions, and mandatory labs do not require the services.

• Amazon DynamoDB — Point-in-time recovery — Official current continuous-backup window and PITR behavior.
• DynamoDB — Restore to a point in time — Official restore-to-new-table behavior and index-related restore implications.
• Azure Cosmos DB — Continuous backup/PITR — Official current retention/restore model and multi-region backup notes.
• Azure Cosmos DB — Private Link — Official private-endpoint/DNS configuration and public-network considerations.
• Cloud Firestore — Regional endpoints — Official endpoint controls for keeping processing/routing within specified regional boundaries for supported server clients.