---
title: "Conflict-Free Replicated Data Types"
description: "If every update is commutative and idempotent, replicas that receive the same set of updates in any order end in the same state, and no coordination is needed at write time. The cost is that the merge"
canonical: https://lightmysky.com/learn/computing/conflict-free-replicated-data-types-mt_Bhf1nu-9jz
source: https://lightmysky.com/learn/computing/conflict-free-replicated-data-types-mt_Bhf1nu-9jz.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Conflict-Free Replicated Data Types

If every update is commutative and idempotent, replicas that receive the same set of updates in any order end in the same state, and no coordination is needed at write time. The cost is that the merge rule, not the application, decides what concurrent edits mean.

Subject: Computing · Area: Data & Databases · Ages 22 to 24
Page: https://lightmysky.com/learn/computing/conflict-free-replicated-data-types-mt_Bhf1nu-9jz

## Ready when they can

- Say what a merge function has to satisfy for replicas to converge
- Design a counter or a set that converges, and state what its merge does with a concurrent add and remove
- Name a case where automatic convergence produces a state no user intended

## Lesson: Merge rules that make replicas agree

Replicas accept writes without coordinating, then swap updates and merge. If every update path is commutative, associative, and idempotent, all replicas that saw the same updates end in the same state no matter the arrival order. Order stops mattering because the merge erases it.

**Example.** A shared counter gives each replica its own slot. Replica A records 2 adds in its slot and replica B records 3 in its own. Merging takes both slots, so every replica shows 5. A resent update changes nothing, since each slot keeps its highest seen value.

Sets are harder because add and remove of the same element can race. The merge rule must pick: add-wins keeps the element, remove-wins drops it. Both replicas reach the same answer, but the rule chose it, not the users.

**Tip.** Agreement is not intent. With a concurrent add and remove, the merge produces a state mechanically, and it may surprise everyone involved. Use this design where that surprise is harmless, and coordinate where the exact outcome matters.

**Recap.** Order-independent merges converge replicas, but the rule, not the users, settles races.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Distributed Transactions and the Blocking Case of Two-Phase Commit](https://lightmysky.com/learn/computing/distributed-transactions-and-the-blocking-case-of-two-phase-commit-mt_MP_B_a_EwW)