Optimistic concurrency in Firebase - Step-by-Step Execution

Process Flow - Optimistic concurrency

Read document snapshot

↓

Make local changes

↓

Attempt to write with version check

↓

Version matches?

No→Conflict detected

↓

Write succeeds

Read data, change locally, then write back only if data version is unchanged to avoid conflicts.

Execution Sample

Firebase

const docRef = firestore.doc('items/item1');
const snapshot = await docRef.get();
const data = snapshot.data();
const version = data.version;
await firestore.runTransaction(async (transaction) => {
  const freshSnapshot = await transaction.get(docRef);
  if (freshSnapshot.data().version !== version) {
    throw new Error('Conflict detected');
  }
  transaction.update(docRef, { count: data.count + 1, version: version + 1 });
});

Reads a document, increments a count and version, then writes back only if version matches.

Process Table

Step	Action	Data Version Read	Local Change	Version Check	Write Result
1	Read document snapshot	3	N/A	N/A	N/A
2	Increment count locally	3	count + 1	N/A	N/A
3	Attempt write with version=3	3	count + 1, version=4	Check if current version == 3	Success
4	Write completes	4	N/A	N/A	Document updated with version=4
5	Another client tries write with version=3	3	count + 1, version=4	Check if current version == 3	Fail - Conflict detected

💡 Write fails if document version changed since read, ensuring no overwrite of concurrent updates.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
version	N/A	3	3	4	4	3 (stale)
count	N/A	current	current + 1	current + 1	updated	current + 1 (stale)
writeResult	N/A	N/A	N/A	Success	Completed	Fail

Key Moments - 2 Insights

Why does the write fail at step 5 even though the client read version 3?

Because between reading and writing, another client updated the document to version 4 (see step 4), so the version check at step 5 fails to prevent overwriting newer data.

What happens if we don't check the version before writing?

Without version check, writes could overwrite concurrent changes, causing data loss or inconsistency (not shown in execution_table but implied by failure at step 5).

Visual Quiz - 3 Questions

Look at the execution table, what is the document version after step 4?

A 4

B 3

C 5

D 2

💡 Hint

Check the 'Data Version Read' and 'Write Result' columns at step 4.

At which step does the write fail due to a version conflict?

A Step 3

B Step 5

C Step 4

D Step 2

💡 Hint

Look for 'Fail - Conflict detected' in the 'Write Result' column.

If the version check was removed, how would the write result at step 5 change?

A It would still fail

B It would cause an error before writing

C It would succeed and overwrite data

D It would retry automatically

💡 Hint

Refer to the 'key_moments' explanation about version checks preventing overwrites.

Concept Snapshot

Optimistic concurrency means:
- Read data with a version number
- Make local changes
- Write back only if version unchanged
- Prevents overwriting others' updates
- Common in Firebase to avoid conflicts

Full Transcript

Optimistic concurrency in Firebase means you first read a document including its version number. Then you make changes locally. When you write back, you check if the version is still the same. If yes, the write succeeds and increments the version. If no, the write fails because someone else updated the document meanwhile. This prevents data conflicts and lost updates. The execution table shows reading version 3, updating to 4, and a later write failing because the version changed. This method helps keep data consistent when many clients update the same document.