Optimistic concurrency in Firebase - Deep Dive

Overview - Optimistic concurrency

What is it?

Optimistic concurrency is a way to handle multiple users trying to change the same data at the same time without conflicts. Instead of locking the data, it assumes conflicts are rare and checks for changes before saving. If a conflict is detected, the operation is retried or rejected. This method helps keep data consistent in apps like Firebase where many users can update data simultaneously.

Why it matters

Without optimistic concurrency, users might overwrite each other's changes, causing data loss or errors. It solves the problem of managing simultaneous updates smoothly, especially in cloud apps with many users. Without it, apps would need slow locks or complex coordination, making them less responsive and harder to scale.

Where it fits

Before learning optimistic concurrency, you should understand basic database operations and the problem of concurrent data access. After this, you can learn about other concurrency controls like pessimistic locking and conflict resolution strategies in distributed systems.

Mental Model

Core Idea

Optimistic concurrency assumes no conflicts will happen and checks for changes only when saving data to avoid overwriting others' updates.

Think of it like...

It's like writing a shared grocery list on a whiteboard without asking for permission first, but before erasing and adding your items, you check if someone else changed the list since you last looked.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Read Data     │──────▶│ Make Changes  │──────▶│ Check Version │
└───────────────┘       └───────────────┘       └───────────────┘
                                   │                      │
                                   ▼                      ▼
                          ┌───────────────┐       ┌───────────────┐
                          │ Version Match │◀──────│ Conflict?     │
                          └───────────────┘       └───────────────┘
                                   │                      │
                      Yes ──────────┘                      └─ No
                                   ▼                      ▼
                          ┌───────────────┐       ┌───────────────┐
                          │ Save Data     │       │ Retry or Fail │
                          └───────────────┘       └───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding concurrent data updates

Concept: Introduce the problem of multiple users updating the same data at once.

Imagine two friends editing the same note on their phones at the same time. Without coordination, one friend's changes might overwrite the other's. This is the core problem of concurrency in data systems.

Result

You see that simultaneous updates can cause data loss or confusion if not managed.

Understanding the problem of concurrent updates is essential before learning how to prevent conflicts.

2

Foundation

Basics of version checking

Concept: Introduce the idea of tracking data versions to detect changes.

Each time data is saved, it gets a version number or timestamp. When you want to update, you check if the version you read matches the current version. If it does, you save; if not, someone else changed it first.

Result

You learn how version checking helps detect if data changed between reading and writing.

Version checking is the key mechanism that enables optimistic concurrency to detect conflicts.

3

Intermediate

How optimistic concurrency works in Firebase

🤔Before reading on: do you think Firebase locks data during updates or checks versions after changes? Commit to your answer.

Concept: Explain Firebase's approach using transactions and version checks to handle concurrency.

Firebase uses transactions that read data, let you modify it, then check if the data changed before saving. If it did, Firebase retries the transaction automatically until it succeeds or fails after several tries.

Result

You understand Firebase's automatic retry mechanism to handle conflicts without locking.

Knowing Firebase retries transactions helps you design apps that handle conflicts gracefully without manual locking.

4

Intermediate

Handling conflicts and retries

🤔Before reading on: do you think retries happen instantly or require user action? Commit to your answer.

Concept: Learn how conflicts trigger retries and how to handle failures after retries.

When a conflict is detected, Firebase retries the transaction a few times automatically. If it still fails, your app can show an error or ask the user to try again. This keeps data consistent without blocking users.

Result

You see how automatic retries improve user experience and data integrity.

Understanding retries prevents confusion about why updates sometimes take longer or fail.

5

Advanced

Designing data models for optimistic concurrency

🤔Before reading on: do you think all data types work equally well with optimistic concurrency? Commit to your answer.

Concept: Learn how to structure data to minimize conflicts and improve concurrency success.

Splitting data into smaller pieces or using counters and timestamps can reduce conflicts. For example, storing user comments separately avoids conflicts when many users add comments simultaneously.

Result

You learn to design data that fits optimistic concurrency well, reducing retries and errors.

Knowing how data design affects concurrency helps build scalable, user-friendly apps.

6

Expert

Limitations and edge cases of optimistic concurrency

🤔Before reading on: do you think optimistic concurrency guarantees zero conflicts? Commit to your answer.

Concept: Explore situations where optimistic concurrency may fail or cause issues.

In very high contention scenarios, many retries can slow down the app or cause failures. Also, if updates depend on complex calculations, conflicts may cause inconsistent results. Sometimes, pessimistic locking or other methods are better.

Result

You understand when optimistic concurrency is not enough and what risks exist.

Recognizing limits helps choose the right concurrency control for your app's needs.

Under the Hood

Optimistic concurrency works by storing a version or timestamp with each data item. When a client reads data, it notes the version. Before writing back, it compares the current version in the database with the one it read. If they match, the write proceeds and the version increments. If not, a conflict is detected, triggering a retry or failure. Firebase implements this using transactions that automatically retry on conflicts, ensuring atomic updates without locking.

Why designed this way?

This method was chosen to avoid the performance and complexity costs of locking data, which can slow down systems and cause deadlocks. Optimistic concurrency assumes conflicts are rare, so it optimizes for the common case of no conflict. It also fits well with distributed cloud systems like Firebase where locking is difficult or impossible due to latency and scale.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Client reads  │──────▶│ Client modifies│──────▶│ Client sends  │
│ data + version│       │ data locally   │       │ update + version│
└───────────────┘       └───────────────┘       └───────────────┘
                                   │                      │
                                   ▼                      ▼
                          ┌───────────────┐       ┌───────────────┐
                          │ Server checks │◀──────│ Current data   │
                          │ version match │       │ version       │
                          └───────────────┘       └───────────────┘
                                   │                      │
                      Yes ──────────┘                      └─ No
                                   ▼                      ▼
                          ┌───────────────┐       ┌───────────────┐
                          │ Save update   │       │ Reject update │
                          │ and increment │       │ and retry     │
                          │ version       │       └───────────────┘
                          └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does optimistic concurrency lock data during updates? Commit to yes or no.

Common Belief: Optimistic concurrency locks data to prevent others from changing it during updates.

Reality: It does not lock data; it allows concurrent changes and detects conflicts only when saving.

Why it matters: Believing it locks data can lead to wrong assumptions about app performance and scalability.

Quick: Do you think optimistic concurrency guarantees no conflicts ever? Commit to yes or no.

Common Belief: Optimistic concurrency completely prevents conflicts from happening.

Reality: It only detects conflicts after they happen and handles them by retrying or failing.

Why it matters: Expecting zero conflicts can cause surprise and bugs when conflicts do occur.

Quick: Is optimistic concurrency always the best choice for all apps? Commit to yes or no.

Common Belief: Optimistic concurrency is the best concurrency control method for every situation.

Reality: It works best when conflicts are rare; in high-conflict scenarios, other methods like locking may be better.

Why it matters: Using optimistic concurrency in the wrong context can cause poor performance and user frustration.

Quick: Does Firebase automatically retry failed transactions indefinitely? Commit to yes or no.

Common Belief: Firebase retries failed transactions forever until they succeed.

Reality: Firebase retries a limited number of times before failing the transaction.

Why it matters: Assuming infinite retries can cause developers to miss handling failure cases properly.

Expert Zone

1

Firebase transactions are atomic but only within a single document or node; cross-document transactions require careful design.

2

The retry mechanism can cause increased latency under heavy load, so monitoring and backoff strategies are important.

3

Version checks rely on consistent server timestamps; clock skew or offline clients can complicate conflict detection.

When NOT to use

Avoid optimistic concurrency when your app has very high write conflicts or requires strict sequential updates. Instead, use pessimistic locking, queue-based updates, or centralized coordination to ensure consistency.

Production Patterns

In production, developers combine optimistic concurrency with user-friendly conflict resolution UI, splitting data into small chunks to reduce conflicts, and monitoring retry rates to detect hotspots.

Connections

Pessimistic concurrency

Opposite approach to concurrency control

Understanding optimistic concurrency helps clarify why pessimistic locking can cause delays and deadlocks, highlighting trade-offs in concurrency design.

Version control systems (e.g., Git)

Similar conflict detection and resolution patterns

Knowing optimistic concurrency deepens understanding of how version control detects conflicting changes and merges them.

Traffic intersection management

Both manage multiple agents trying to use shared resources without collisions

Seeing concurrency control like traffic flow helps grasp why some methods block (traffic lights) and others detect conflicts after they happen (stop signs).

Common Pitfalls

#1 Ignoring conflict handling and assuming updates always succeed.

Wrong approach:

firebase.firestore().runTransaction(transaction => {
const doc = transaction.get(docRef);
transaction.update(docRef, { count: doc.data().count + 1 });
});

Correct approach:

firebase.firestore().runTransaction(async transaction => {
const doc = await transaction.get(docRef);
if (!doc.exists) throw 'Document missing';
transaction.update(docRef, { count: doc.data().count + 1 });
});

Root cause:

Not awaiting the document read causes the update to use stale data, leading to conflicts or errors.

#2 Designing data models that cause frequent conflicts.

Wrong approach:

Storing all user comments in a single document and updating it for every new comment.

Correct approach:

Storing each comment as a separate document to avoid write conflicts.

Root cause:

Not considering how data structure affects concurrency leads to unnecessary retries and poor performance.

#3 Assuming Firebase retries transactions forever.

Wrong approach:

No error handling after transaction call, expecting infinite retries.

Correct approach:

Adding catch blocks to handle transaction failures after retry limit is reached.

Root cause:

Misunderstanding Firebase's retry limits causes unhandled errors and bad user experience.

Key Takeaways

Optimistic concurrency lets multiple users update data without locking by checking versions before saving.

It works best when conflicts are rare and uses retries to handle occasional conflicts automatically.

Firebase implements optimistic concurrency with transactions that retry updates if data changed meanwhile.

Good data design reduces conflicts and improves app performance under optimistic concurrency.

Knowing its limits helps choose the right concurrency method and handle failures gracefully.