Cosmos DB conflict resolution

Understand the concept

In plain English

Cosmos DB conflict resolution is how Cosmos DB decides what happens when multiple writable regions update the same item at nearly the same time. In a single-write-region design, conflicts are usually avoided by routing writes to one place. In a multi-region-write design, the container needs a policy, commonly Last Write Wins or custom logic where supported. The idea sounds simple, but it affects real business meaning. A later timestamp may not equal the correct inventory count, account balance, workflow state, or user decision.

Why it matters

Cosmos DB conflict resolution matters because active-active writes can improve availability and local latency, but they also create business ambiguity. If two regions update the same profile, inventory record, or service ticket, the database needs a deterministic answer. Last Write Wins is simple and fast, but it can discard a meaningful earlier update. Custom logic can better reflect business rules but adds design and operational complexity. Readers should understand that conflict policy is not just a database checkbox. It is a contract between application semantics, regional architecture, data model, and incident response when concurrent writes happen. This prevents teams from turning a platform option into an undocumented production assumption.

Technical context

Technically, conflict resolution is configured for containers used with multi-region writes. Cosmos DB can resolve conflicts with Last Write Wins based on a timestamp or configured numeric path, and selected APIs can use custom resolution logic. The policy is typically chosen when the container is created, so late changes may require redesign or migration. Architects must understand which items can be updated concurrently, whether conflicts are acceptable, how conflict feed visibility works, and which application operations need idempotency, versioning, or business-specific merge rules.

Exam context

Compare with

Where it is used

Where you see it

1. In container creation or IaC, it appears as conflict resolution policy settings, Last Write Wins paths, custom policy references, and multi-region write design notes during production reviews and runbooks.
2. In incident reviews, it appears when users report lost updates, duplicate changes, unexpected record state, or region-specific writes winning over another region in release reviews and support tickets.
3. In monitoring and runbooks, it appears beside conflict counts, write-region activity, retry logs, replication health, affected partition keys, and reconciliation workflows during incident triage and architecture reviews.

Common situations

• Support active-active regional writes with deterministic conflict handling.
• Choose Last Write Wins for safe overwrite-style records.
• Use custom or application-level reconciliation for business-critical updates.
• Document container-level conflict behavior before enabling multi-region writes.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

Use CLI to inspect account multi-region settings and container conflict policy before diagnosing lost updates or active-active write behavior.

az cosmosdb show --name <account> --resource-group <resource-group>

az cosmosdb sql container show --account-name <account> --resource-group <resource-group> --database-name <database> --name <container>

az cosmosdb sql container create --account-name <account> --resource-group <resource-group> --database-name <database> --name <container> --partition-key-path <path>

Architecture context

Cosmos DB conflict resolution is an application correctness decision for multi-region write designs. I review it before enabling active-active writes because the database must know what to do when two regions update the same logical item. Last Write Wins may be acceptable for telemetry or replaceable profile data, but it can be dangerous for inventory, financial state, or workflow approvals. The architecture should define conflict policy, conflict path where used, custom handling where supported, user experience, and audit evidence. Operators need to inspect account write regions, container policy, conflict feed behavior, and application logs during drills. Multi-region writes improve locality and resilience, but conflict resolution determines whether the business can trust the result.

Security

Security for Cosmos DB conflict resolution includes protecting who can enable multi-region writes, create containers with conflict policies, update conflict-related application code, and inspect conflict data. Conflicts may contain sensitive prior versions or business decisions, so logs and troubleshooting tools need access controls. A malicious or buggy client in one region could intentionally win Last Write Wins by sending newer values unless application validation prevents it. Teams should use private networking, least-privilege administration, diagnostics, and change control for policy creation. Security reviews should confirm that conflict handling does not bypass approval workflows, audit trails, or data integrity checks. Include access evidence, data classification, and removal procedures in the production checklist.

Cost

Cost for Cosmos DB conflict resolution is tied to the broader multi-region-write design. Multiple writable regions increase replicated write activity, monitoring, testing, and operational complexity. Custom resolution logic or reconciliation workflows can add compute, storage, and support cost. Last Write Wins may appear cheap but can become expensive if lost updates trigger manual repair, refunds, or compliance investigations. Cost reviews should compare active-active benefit against the frequency and impact of conflicts. Sometimes a single write region with regional reads, command routing, or application-level queues is cheaper and safer than paying for multi-write behavior the business does not actually need.

Reliability

Reliability for Cosmos DB conflict resolution depends on whether concurrent writes are expected, modeled, and tested. Multi-region writes should not be enabled simply to improve latency if the application cannot tolerate lost updates. Reliable designs identify conflict-prone entities, use partitioning and item design to reduce collisions, and make operations idempotent where possible. Teams should test simultaneous writes, regional failover, retry storms, and clock-related assumptions. Monitoring should include conflict rates, write latency, replication health, and application-level reconciliation results. A reliable conflict strategy includes human escalation when automatic policy cannot safely choose the business outcome. Include realistic failure drills, owner escalation, and recovery evidence in the runbook.

Performance

Performance for Cosmos DB conflict resolution depends on regional write latency, replication, consistency, partition activity, conflict rate, and the complexity of any custom handling. Last Write Wins is operationally simple, but performance metrics alone cannot prove correctness. Heavy conflicts on the same logical partition can create retries, wasted RU, and application confusion. Teams should test active-active writes with realistic concurrency and failure conditions. Monitor write latency, request charge, conflict counts, retry behavior, and reconciliation duration. Performance tuning may require changing item granularity so independent updates do not fight over the same document. Validate tuning with representative traffic, documented baselines, and user-facing service targets.

Operations

Operationally, Cosmos DB conflict resolution needs documentation for each multi-write container explaining the chosen policy, conflict path, supported API behavior, and business owner. Runbooks should show how to detect conflict spikes, inspect unresolved or custom-handled cases where applicable, and reconcile data when automation produces an unacceptable result. Operators need to know whether Last Write Wins is acceptable for the workload or merely convenient. Container creation templates should include policy settings, because changing them later can be difficult. During incidents, teams should gather timestamps, regions, client versions, and affected partition keys before repairing data. Keep ownership, dashboard links, deployment history, and support escalation steps current.

Common mistakes

• Using Last Write Wins for data that requires business merging.
• Enabling multi-region writes before testing concurrent updates.
• Forgetting that conflict policy is usually a container creation decision.