Forem: Pulkit Midha

What Happens If Two Android Phones Edit the Same Data Offline?

Pulkit Midha — Thu, 29 Jan 2026 09:41:03 +0000

Short answer: Chaos, unless you planned for it.

Long answer: Let me show you what actually happens when distributed systems meet the real world.

The Scenario

You build an app. Users love it. They install it on multiple devices. Everything works great until one day you get a support ticket:

"I edited my shopping list on my phone, then edited it on my tablet, and now half my items are missing. What happened?"

What happened is that you just learned about conflict resolution the hard way.

The Setup (For Science)

I built a simple test to see exactly what happens. Two Android phones, both running the same app, both offline, both editing the same document at the same time.

// Document before any edits
{
    "id": "shopping-list-1",
    "title": "Groceries",
    "items": ["milk", "eggs", "bread"],
    "lastModified": 1705320000000
}

Phone A (offline): User adds "butter"
Phone B (offline, same time): User adds "cheese"

Then both phones come online. What happens?

Test 1: Naive Last-Write-Wins (The Disaster)

First, I tried the simplest approach: whoever syncs last wins.

// Pseudo-code for simple sync
fun syncDocument(local: Document, remote: Document): Document {
    return if (local.lastModified > remote.lastModified) {
        local  // Local is newer, push it
    } else {
        remote  // Remote is newer, pull it
    }
}

Phone A syncs first:

{
    "id": "shopping-list-1",
    "title": "Groceries",
    "items": ["milk", "eggs", "bread", "butter"],
    "lastModified": 1705320060000
}

Server now has Phone A's version.

Phone B syncs second:

{
    "id": "shopping-list-1",
    "title": "Groceries",
    "items": ["milk", "eggs", "bread", "cheese"],
    "lastModified": 1705320065000  // 5 seconds later
}

Result: Phone B's version overwrites everything. Phone A's "butter" is gone. User is confused. Developer gets a bad review.

This is bad.

Test 2: Timestamp-Based Merge (The Almost Solution)

Okay, timestamps don't work. What if we track timestamps per field?

// Document with field-level timestamps
{
    "id": "shopping-list-1",
    "title": "Groceries",
    "title_modified": 1705320000000,
    "items": ["milk", "eggs", "bread"],
    "items_modified": 1705320000000
}

Phone A adds "butter":

{
    "items": ["milk", "eggs", "bread", "butter"],
    "items_modified": 1705320060000
}

Phone B adds "cheese":

{
    "items": ["milk", "eggs", "bread", "cheese"],
    "items_modified": 1705320065000
}

Merge logic:

fun mergeFields(local: Document, remote: Document): Document {
    val merged = Document()

    if (local.title_modified > remote.title_modified) {
        merged.title = local.title
    } else {
        merged.title = remote.title
    }

    if (local.items_modified > remote.items_modified) {
        merged.items = local.items
    } else {
        merged.items = remote.items
    }

    return merged
}

Result: Phone B's items win because the timestamp is newer. We still lose "butter".

This is still bad.

Test 3: Operational Transform (The Complex Solution)

What if we track the actual operations?

Phone A: INSERT "butter" at index 3
Phone B: INSERT "cheese" at index 3

Now we can merge the operations:

{
    "items": ["milk", "eggs", "bread", "butter", "cheese"]
}

Perfect! Both changes preserved!

But here's the implementation:

sealed class Operation {
    data class Insert(val index: Int, val value: String) : Operation()
    data class Delete(val index: Int) : Operation()
    data class Update(val index: Int, val value: String) : Operation()
}

fun transformOperations(
    localOps: List<Operation>,
    remoteOps: List<Operation>,
    baseState: List<String>
): List<String> {
    // This is where you spend 3 weeks implementing OT
    // And discover edge cases you never imagined
    // Like: what if one device deletes while another updates?
    // Or: indices shift during concurrent inserts
    // Or: the operations arrive out of order

    // 500 lines of transformation logic later...
}

This works, but good luck maintaining it. Plus, you need to store and sync all operations. And handle out-of-order arrival. And... you get the idea.

Test 4: CRDTs (The Academic Solution)

Conflict-Free Replicated Data Types. Super cool in theory.

// A simple LWW-Element-Set CRDT
class LWWSet<T> {
    private val adds = mutableMapOf<T, Long>()  // Element -> timestamp
    private val removes = mutableMapOf<T, Long>()

    fun add(element: T, timestamp: Long) {
        adds[element] = maxOf(adds[element] ?: 0, timestamp)
    }

    fun remove(element: T, timestamp: Long) {
        removes[element] = maxOf(removes[element] ?: 0, timestamp)
    }

    fun elements(): Set<T> {
        return adds.filter { (element, addTime) ->
            val removeTime = removes[element] ?: 0
            addTime >= removeTime
        }.keys
    }

    fun merge(other: LWWSet<T>) {
        other.adds.forEach { (element, timestamp) ->
            add(element, timestamp)
        }
        other.removes.forEach { (element, timestamp) ->
            remove(element, timestamp)
        }
    }
}

Phone A adds "butter" at time 60:

lwwSet.add("butter", 1705320060000)

Phone B adds "cheese" at time 65:

lwwSet.add("cheese", 1705320065000)

Merge:

lwwSet.merge(otherSet)
// Result: ["milk", "eggs", "bread", "butter", "cheese"]

This works! Both edits preserved!

But now your data structure is completely different. And you need to implement CRDTs for every data type. And explain to your team what a CRDT is. And...

There has to be a better way.

Test 5: Couchbase Lite (The Practical Solution)

Couchbase uses a revision tree. Every change creates a new revision. Conflicts are detected automatically.

Let me show you what actually happens:

Initial document (revision 1-abc):

{
    "id": "shopping-list-1",
    "title": "Groceries",
    "items": ["milk", "eggs", "bread"],
    "_rev": "1-abc"
}

Phone A (offline) adds "butter" -> creates revision 2-def:

{
    "id": "shopping-list-1",
    "title": "Groceries",
    "items": ["milk", "eggs", "bread", "butter"],
    "_rev": "2-def",
    "_revisions": {
        "start": 2,
        "ids": ["def", "abc"]
    }
}

Phone B (offline) adds "cheese" -> creates revision 2-ghi:

{
    "id": "shopping-list-1",
    "title": "Groceries",
    "items": ["milk", "eggs", "bread", "cheese"],
    "_rev": "2-ghi",
    "_revisions": {
        "start": 2,
        "ids": ["ghi", "abc"]
    }
}

Both revisions branched from 1-abc. This is a conflict.

When sync happens:

Couchbase detects the conflict because two revisions have the same parent. It marks one as the "winner" (deterministically based on revision ID), but keeps both.

// Phone A's view after sync
{
    "id": "shopping-list-1",
    "_rev": "2-ghi",  // Winner (alphabetically later)
    "items": ["milk", "eggs", "bread", "cheese"],
    "_conflicts": ["2-def"]  // Loser is preserved
}

Now here's the cool part: I can write a custom conflict resolver.

val config = ReplicatorConfigurationFactory.create(
    database = database,
    target = endpoint,
    conflictResolver = { conflict ->
        val local = conflict.localDocument
        val remote = conflict.remoteDocument

        // Both documents exist, merge the items
        val localItems = local.getArray("items")?.toList() ?: emptyList()
        val remoteItems = remote.getArray("items")?.toList() ?: emptyList()

        // Merge: take all unique items from both
        val mergedItems = (localItems + remoteItems).distinct()

        val merged = MutableDocument(local.id)
        merged.setString("title", local.getString("title"))
        merged.setArray("items", MutableArray(mergedItems))
        merged.setLong("lastModified", System.currentTimeMillis())

        merged
    }
)

Result after conflict resolution:

{
    "id": "shopping-list-1",
    "title": "Groceries",
    "items": ["milk", "eggs", "bread", "butter", "cheese"],
    "_rev": "3-xyz"
}

Both edits preserved. No data loss. Automatic sync. Beautiful.

The Real-World Test

I actually tested this with two physical devices:

Test A: Concurrent Adds

Phone 1 (offline): Add "tomatoes"
Phone 2 (offline): Add "onions"
Both come online
Result: Both items appear
✅ Success

Test B: Concurrent Updates to Same Item

Both phones have item: "apples (2)"
Phone 1 (offline): Change to "apples (3)"
Phone 2 (offline): Change to "apples (5)"
Both come online
Result: My resolver kept the higher quantity
✅ Success (with custom logic)

Test C: Delete vs Update

Phone 1 (offline): Delete item "bananas"
Phone 2 (offline): Update "bananas" to "bananas (ripe)"
Both come online
Result: My resolver keeps the update (prefer data retention)
✅ Success (with custom logic)

Test D: Complete List Reorder

Phone 1 (offline): Reorder list A-Z
Phone 2 (offline): Reorder list by category
Both come online
Result: Last sync wins (can't merge reorders intelligently)
⚠️ Acceptable loss

What About Room?

Could you build this with Room? Technically yes. Would you want to? No.

You'd need:

Manual revision tracking
Conflict detection logic
Merge algorithms
Sync coordination
Server-side conflict resolution
At least 1000 lines of code

Or you could use Couchbase and write 50 lines.

The Code

Here's my complete conflict resolver for the shopping list:

private fun resolveShoppingListConflict(conflict: Conflict): Document {
    val local = conflict.localDocument ?: return conflict.remoteDocument!!
    val remote = conflict.remoteDocument ?: return local

    // Get items from both versions
    val localItems = mutableSetOf<String>()
    local.getArray("items")?.forEach { item ->
        (item as? String)?.let { localItems.add(it) }
    }

    val remoteItems = mutableSetOf<String>()
    remote.getArray("items")?.forEach { item ->
        (item as? String)?.let { remoteItems.add(it) }
    }

    // Merge: union of both sets
    val mergedItems = localItems + remoteItems

    // Create merged document
    val merged = MutableDocument(local.id)
    merged.setString("title", local.getString("title") ?: remote.getString("title") ?: "")
    merged.setArray("items", MutableArray(mergedItems.toList()))
    merged.setLong("lastModified", System.currentTimeMillis())
    merged.setString("type", "shopping-list")

    return merged
}

That's it. 25 lines. Handles all concurrent edits.

Performance Impact

I measured sync times with conflicts:

No conflict:

Sync time: ~100ms
Network: 1 request

With conflict (default resolver):

Sync time: ~120ms
Network: 2 requests (detect + resolve)

With conflict (custom resolver):

Sync time: ~150ms
Network: 2 requests

The overhead is minimal. Users won't notice.

Edge Cases I Discovered

Same Edit on Both Devices

If both phones add "butter" while offline, the default resolver recognizes they're identical and doesn't create a conflict. Smart.

Very Old Offline Edit

Phone A goes offline for a week. Makes edits. Comes back online. Phone B has made 50 changes in that time.

Couchbase's revision tree handles this. It merges based on the branching point, not the absolute time. Works perfectly.

Three-Way Conflicts

Phone A, Phone B, and Phone C all edit while offline. All sync at once.

Couchbase resolves them pairwise. My resolver runs multiple times. Final result includes all changes. Magic.

When It Doesn't Work

Not all conflicts can be auto-resolved:

Semantic Conflicts

Phone A: Set meeting time to 2 PM
Phone B: Set meeting time to 4 PM

Which is correct? The resolver doesn't know. You need user intervention.

My solution: surface conflicts to the user when they're ambiguous.

private fun requiresUserIntervention(conflict: Conflict): Boolean {
    val local = conflict.localDocument ?: return false
    val remote = conflict.remoteDocument ?: return false

    // Same field changed to different values?
    val criticalFields = listOf("meetingTime", "price", "quantity")

    return criticalFields.any { field ->
        local.getValue(field) != remote.getValue(field) &&
        local.getValue(field) != null &&
        remote.getValue(field) != null
    }
}

Complex Business Logic

"If status is 'approved', don't allow edits" type rules.

The database doesn't know your business logic. You need to enforce it in the app.

Lessons Learned

Timestamps lie: Clocks aren't synchronized. Never trust timestamps alone.
Last-write-wins loses data: Unless that's explicitly what you want.
Automatic merge is hard: But letting a battle-tested library do it is easy.
Most conflicts are mergeable: 90% of my conflicts merge automatically.
The other 10% need UI: Show users the conflict, let them decide.

Best Practices

1. Design for Conflicts

Assume conflicts will happen. They will.

2. Merge When Possible

Union sets, combine arrays, prefer data retention over deletion.

3. Let Users Decide When Unsure

Don't silently discard data.

4. Test With Real Devices

Emulators don't capture the real experience of offline editing.

5. Log Everything

When conflicts happen, log them. You'll learn patterns.

The Bottom Line

Two phones editing the same data offline is not a hypothetical. It's a real scenario that happens all the time:

User edits doc on phone during commute (no signal)
User edits same doc on laptop at office
Both sync when user arrives

If you're building multi-device apps, you need a conflict resolution strategy. You have three options:

Manual implementation: Hard, buggy, time-consuming
Academic solutions (OT/CRDTs): Powerful, complex, overkill for most apps
Use Couchbase Lite: Practical, battle-tested, actually works

I chose option 3. My conflicts resolve automatically. My users don't lose data. I sleep well at night.

Have you dealt with offline conflicts in your apps? What strategies did you use? I'd love to hear about your experiences in the comments.

I Tried to Build Multi-Device Sync with Room (So You Don't Have To)

Pulkit Midha — Thu, 29 Jan 2026 09:37:55 +0000

Look, I get it. Room is great. It's clean, it's type-safe, and it fits perfectly into the Android ecosystem. I've built probably a dozen apps with it, and I've never had complaints. Until last month.

My PM walks up and says, "Hey, can we sync this data across devices?" Sure, I thought. How hard could it be?

Spoiler: Very hard.

The Plan (That Seemed Reasonable at 9 AM)

I had a simple notes app using Room. The schema was straightforward:

@Entity(tableName = "notes")
data class Note(
    @PrimaryKey val id: String = UUID.randomUUID().toString(),
    val title: String,
    val content: String,
    val lastModified: Long = System.currentTimeMillis()
)

My brilliant plan:

Set up a REST API on the backend
Send local changes to the server
Pull remote changes and merge them
Profit?

Reality Check 1: The Manual API Hell

First problem: Room doesn't have any built-in sync. Everything is manual. So I had to:

Track which notes were dirty (modified locally)
Queue them for upload
Handle network failures
Retry failed uploads
Deal with partial syncs
Track sync state per note

I ended up adding fields to my entity:

@Entity(tableName = "notes")
data class Note(
    @PrimaryKey val id: String = UUID.randomUUID().toString(),
    val title: String,
    val content: String,
    val lastModified: Long = System.currentTimeMillis(),
    val syncStatus: SyncStatus = SyncStatus.PENDING,
    val lastSyncedAt: Long? = null,
    val isDirty: Boolean = false
)

Great. Now my clean entity is cluttered with sync metadata.

Reality Check 2: Conflict Hell

Here's where things got fun. User edits "Meeting Notes" on their phone, then edits the same note on their tablet before the phone syncs. Which version wins?

My first attempt: "Last write wins based on timestamp."

Sounds reasonable, right? Except:

Clocks aren't always in sync
Network delays mean "last" is relative
Users get really mad when their edits disappear

I tried version vectors. I tried vector clocks. I tried telling myself this was a learning experience.

// My attempt at conflict resolution
fun resolveConflict(local: Note, remote: Note): Note {
    return when {
        local.lastModified > remote.lastModified -> local
        local.lastModified < remote.lastModified -> remote
        else -> {
            // Same timestamp? Now what?
            // Merge content? Prompt user? Flip a coin?
            Log.e("Sync", "Help")
            remote // I gave up
        }
    }
}

Reality Check 3: The Duplicate Row Problem

You know what's worse than losing data? Having two copies of the same note because the UUID generated on the phone doesn't match the ID the server assigned.

I had to implement ID mapping:

data class IdMapping(
    val localId: String,
    val remoteId: String
)

And a whole separate table to track it. My "simple" sync was now three tables deep.

Reality Check 4: Race Conditions Everywhere

User opens app while sync is running -> stale data
User edits note during sync -> which version do we keep?
Sync starts while user is editing -> UI flickers
Multiple devices sync at once -> chaos

I added locks. I added queues. I added way too many synchronized blocks. My code was starting to look like a threading textbook gone wrong.

private val syncLock = ReentrantReadWriteLock()

suspend fun syncNotes() {
    syncLock.writeLock().lock()
    try {
        // 50 lines of sync logic
        // 30 lines of error handling
        // 10 lines of "TODO: fix this properly"
    } finally {
        syncLock.writeLock().unlock()
    }
}

Breaking Point

After two weeks of this, I had:

800+ lines of sync code
15 different edge cases in my test suite
A bug where notes would randomly duplicate
Another bug where deletions wouldn't sync
A third bug that only happened on Tuesdays (I'm not joking)

I started Googling alternatives.

Enter Couchbase Lite

I'm not going to lie, I was skeptical. "Just use another database" felt like giving up. But I was desperate.

The setup:

// That's it. That's the entire initial setup.
val database = Database("myapp")

Adding sync:

val replicator = Replicator(
    ReplicatorConfigurationFactory.create(
        database = database,
        target = URLEndpoint(URI("ws://localhost:4984/mydb")),
        type = ReplicatorType.PUSH_AND_PULL,
        continuous = true
    )
)
replicator.start()

That's it. No sync status tracking. No conflict resolution hell. No duplicate IDs. It just... works.

How It Actually Handles Conflicts

Remember my terrible conflict resolution code? Couchbase does this automatically:

// Define custom conflict resolver if you need it
val config = ReplicatorConfigurationFactory.create(
    database = database,
    target = target,
    conflictResolver = { conflict ->
        val local = conflict.localDocument
        val remote = conflict.remoteDocument
        // Actually merge the content intelligently
        // Or just pick one
        local // Your choice, but it won't lose data randomly
    }
)

But honestly? The default resolver is pretty smart. It maintains revision history and merges changes. I haven't had to write a custom resolver yet.

What About the Learning Curve?

Not gonna lie, there's some new concepts:

Documents instead of entities
Revision IDs
The whole CouchDB replication protocol

But compared to implementing sync from scratch? This is a weekend, not a month.

The Numbers

Room + Manual Sync:

800+ lines of sync code
2 weeks of development
Still had bugs
Nervous about scaling

Couchbase Lite:

~50 lines for full sync setup
1 day to integrate
Zero sync bugs so far
Built-in conflict resolution

Should You Switch?

Look, if you're building a single-device app that never needs to sync, stick with Room. It's lighter and simpler.

But if you're even thinking about:

Multi-device sync
Offline-first architecture
Real-time collaboration
Data conflicts between devices

Save yourself the pain. Use Couchbase Lite from the start.

The Catch

There's always a catch:

Slightly larger APK size
Need to run Sync Gateway for server sync
Different query syntax (though it's SQL-like)

For me? Totally worth it. My sync code went from "oh god why" to "oh, it just works."

Final Thoughts

I spent two weeks trying to reinvent the wheel with Room. Turns out, other people have already solved this problem, and they did a better job than I ever would.

Sometimes the right tool isn't the one you're already comfortable with. Sometimes it's the one that actually solves your problem.

Now if you'll excuse me, I have 800 lines of sync code to delete.

Have you tried implementing sync with Room? Did you succeed where I failed? Or did you also end up Googling "why is distributed systems so hard" at 2 AM? Let me know in the comments.