The Fundamental Problem
Two users edit the same piece of data at the same time. User A changes the task title. User B changes the same task title at the same moment. When their changes sync, whose version wins?
This is the fundamental problem of distributed data: concurrent writes to shared state. Every collaborative application must solve it. The solutions range from simple (locking — only one person can edit at a time) to complex (CRDTs — changes merge automatically without coordination).
A Brief History of Conflict Resolution
Locking (1990s–2000s)
The first generation of collaborative tools used locking. When you open a document, it’s locked for everyone else. This prevents conflicts entirely but destroys collaboration — the “shared” in “shared document” becomes “takes turns.”
Last Write Wins (2000s–2010s)
The next generation used LWW at the record level. The most recent write overwrites the entire record. Simple to implement, but data loss is common. If you update the title and your teammate updates the description, one of those changes is lost.
Operational Transformation (2010s)
Google Docs popularized OT: every edit is an operation (insert character at position X, delete characters Y–Z), and concurrent operations are transformed against each other to produce a consistent result. OT works well for text editing but is complex to implement and hard to reason about for structured data.
CRDTs (2010s–Present)
Conflict-free Replicated Data Types are data structures that can be modified independently on multiple replicas and merged deterministically without coordination. The “conflict-free” part means that any order of applying operations produces the same result — there’s no conflict to resolve.
How CRDTs Work (Simplified)
A CRDT is a data structure where:
- Every replica can be modified independently
- Modifications can be merged in any order
- The merge always produces the same result (mathematical convergence)
The simplest CRDT is a counter. Each replica keeps a local count. When replicas merge, they take the maximum of each replica’s count. This works because max() is commutative and idempotent — merging in any order produces the same result.
For more complex data types — maps, sets, ordered lists, rich text — CRDTs become more sophisticated. Libraries like Yjs, Automerge, and Diamond Types implement CRDT-based data structures for collaborative applications.
How FlowEra Applies These Principles
FlowEra uses a hybrid approach tailored to the specific data types in a task management tool:
Structured Task Data: Field-Level LWW
For task fields (title, status, assignee, custom fields), FlowEra uses field-level last-write-wins with server-authoritative timestamps. Each field is an independent unit of conflict resolution. If you change the title and your teammate changes the status, both changes survive.
This is not a full CRDT, but it provides the most important property: independent edits to different fields never conflict. For the rare case of concurrent edits to the same field, the server timestamp determines which value wins. In practice, two people editing the same field at the same millisecond is rare enough that LWW is acceptable.
Rich Text (Knowledge Base): OT/CRDT
For the knowledge base editor, where multiple people may type in the same paragraph simultaneously, FlowEra uses operational transformation for real-time collaborative editing. This is the appropriate technology for text collaboration — every keystroke from every collaborator is preserved and merged, character by character.
Ordering (Kanban, Lists): Fractional Indexing
For task ordering on the Kanban board and in lists, FlowEra uses fractional indexing. Each task has a sort key that’s a fraction between 0 and 1. Moving a task between two others assigns it a sort key between its neighbors. This allows concurrent reordering operations to produce a consistent result without conflicts — each move is independent of other moves.
The Trade-offs
No conflict resolution strategy is perfect for all use cases:
LWW loses data when the same field is edited concurrently. For task management, this is acceptable because concurrent edits to the same field are rare and the stakes are low (a task title, not a financial transaction).
OT is complex and centralized. The server must process operations in order, which limits scalability. For knowledge base editing with a few concurrent editors, this is fine.
Full CRDTs add metadata overhead. Every operation carries vector clocks or version vectors, increasing storage and bandwidth. For high-throughput structured data (thousands of task updates per second), this overhead is significant.
FlowEra’s hybrid approach matches the conflict resolution strategy to the data type, optimizing for the common case in each context.
Why This Matters for Users
Users shouldn’t need to understand CRDTs. What they should experience is: I made a change, my teammate made a change, both changes are there. No “conflict” dialogs. No lost data. No “please refresh.”
The technology is invisible when it works. And that’s the point.