Optimistic concurrency in Firebase - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is optimistic concurrency in Firebase?

Optimistic concurrency is a way to handle data updates where multiple users can try to change data at the same time. Firebase checks if the data was changed by someone else before saving your update. If it was, your update is rejected to avoid conflicts.

intermediate

How does Firebase detect conflicts in optimistic concurrency?

Firebase uses a version or timestamp on data. When you update, it compares the current version with the one you read. If they differ, it means someone else changed the data, so your update is rejected.

beginner

Why is optimistic concurrency useful in cloud databases like Firebase?

It allows many users to work on data without locking it. This makes apps faster and more responsive because users don’t wait for locks. Conflicts are rare and handled only when they happen.

intermediate

What happens if a conflict is detected during an optimistic concurrency update in Firebase?

Firebase rejects the update and returns an error. The app can then reload the latest data and ask the user to try again or merge changes.

advanced

Compare optimistic concurrency with pessimistic concurrency.

Optimistic concurrency assumes conflicts are rare and checks for them only when saving. Pessimistic concurrency locks data to prevent others from changing it until the lock is released. Firebase uses optimistic concurrency for better speed and user experience.

What does Firebase check to detect a conflict in optimistic concurrency?

A If the data version or timestamp has changed since last read

B If the user has admin rights

C If the network connection is stable

D If the data size exceeds limits

Firebase compares the version or timestamp of the data to detect if it was changed by someone else before saving your update.

What happens when Firebase detects a conflict during an update?

A It rejects the update and returns an error

B It ignores the conflict and saves anyway

C It locks the data for the user

D It automatically merges changes

Firebase rejects the update to prevent overwriting changes made by others and returns an error.

Why is optimistic concurrency preferred in Firebase over pessimistic concurrency?

A Because it locks data for faster updates

B Because it requires less network bandwidth

C Because it assumes conflicts are rare and avoids locking

D Because it automatically backs up data

Optimistic concurrency avoids locking data, improving speed and user experience by assuming conflicts are rare.

Which of these is a key benefit of optimistic concurrency?

A Updates are never rejected

B Data is always locked during updates

C Users wait for locks to release

D Multiple users can work on data simultaneously

Optimistic concurrency allows multiple users to work on data at the same time without locking.

If your update is rejected due to a conflict, what should your app do next?

A Ignore the error and continue

B Reload the latest data and retry or merge changes

C Delete the data

D Restart the Firebase service

The app should reload the latest data and let the user retry or merge changes to resolve the conflict.

Explain how optimistic concurrency works in Firebase and why it is useful.

Think about how Firebase avoids locking data but still keeps data consistent.

Describe the steps your app should take when a conflict is detected during an optimistic concurrency update.

Consider how to handle rejected updates gracefully.

Practice

1. What is the main purpose of optimistic concurrency in Firebase?

easy

A. To automatically backup data every hour

B. To speed up data retrieval by caching results

C. To encrypt data during transmission

D. To prevent overwriting data by checking for changes before updating

Solution

1. Step 1: Understand optimistic concurrency concept

   Optimistic concurrency means checking if data changed before saving updates to avoid overwriting others' changes.

2. Step 2: Match concept to Firebase usage

   Firebase uses transactions to check and update data atomically, which is an example of optimistic concurrency.

3. Final Answer:

   To prevent overwriting data by checking for changes before updating -> Option D

4. Quick Check:

   Optimistic concurrency = prevent overwrites [OK]

Hint: Optimistic concurrency checks data before saving updates [OK]

Common Mistakes:

• Confusing optimistic concurrency with caching
• Thinking it encrypts data
• Assuming it backs up data automatically

2. Which Firebase method is used to safely update data with optimistic concurrency?

easy

A. firebase.database().set()

B. firebase.database().transaction()

C. firebase.database().push()

D. firebase.database().once()

Solution

1. Step 1: Identify methods for data update in Firebase

   Methods like set() overwrite data directly, push() adds new data, once() reads data once.

2. Step 2: Find method supporting atomic update with retry

   transaction() reads current data, applies update, retries if data changed during update, ensuring safe concurrency.

3. Final Answer:

   firebase.database().transaction() -> Option B

4. Quick Check:

   Safe update method = transaction() [OK]

Hint: Use transaction() for atomic updates with concurrency control [OK]

Common Mistakes:

• Using set() which overwrites without concurrency check
• Confusing push() with update methods
• Using once() which only reads data

3. Consider this Firebase transaction code snippet:

const ref = firebase.database().ref('counter');
ref.transaction(current => {
  return (current || 0) + 1;
});

What happens if two users run this code at the same time?

medium

A. The counter increments by 1 only once

B. The counter resets to 0

C. The counter increments by 2 safely without overwriting

D. The transaction fails and throws an error

Solution

1. Step 1: Understand transaction behavior with concurrent updates

   Firebase transactions read current value, apply update, and retry if data changed during update.

2. Step 2: Analyze two concurrent increments

   Both users read current value, increment by 1, but Firebase retries one transaction to avoid overwrite, resulting in counter increasing by 2.

3. Final Answer:

   The counter increments by 2 safely without overwriting -> Option C

4. Quick Check:

   Concurrent transactions = safe increments [OK]

Hint: Transactions retry to avoid overwriting, so increments add up [OK]

Common Mistakes:

• Thinking only one increment happens
• Assuming counter resets
• Believing transaction throws error on conflict

4. You wrote this Firebase transaction:

ref.transaction(current => {
  current = current + 1;
  return current;
});

But sometimes it throws an error. What is the likely problem?

medium

A. current might be null, causing addition to fail

B. transaction() cannot update numbers

C. You must use set() inside transaction

D. Firebase transactions do not support arrow functions

Solution

1. Step 1: Check how current value is used

   If current is null (no data yet), adding 1 to null causes an error.

2. Step 2: Identify fix for null current

   Use (current || 0) + 1 to handle null safely inside transaction.

3. Final Answer:

   current might be null, causing addition to fail -> Option A

4. Quick Check:

   Null current causes error in addition [OK]

Hint: Check for null before arithmetic in transactions [OK]

Common Mistakes:

• Thinking transaction can't update numbers
• Trying to use set() inside transaction callback
• Believing arrow functions are unsupported

5. You want to implement a like counter for a post in Firebase using optimistic concurrency. Which approach ensures the counter updates correctly even if many users like simultaneously?

hard

A. Use ref.transaction(currentLikes => (currentLikes || 0) + 1) to increment safely

B. Use ref.set(currentLikes + 1) without checking current value

C. Read currentLikes once, then call ref.set(currentLikes + 1)

D. Use ref.push() to add a new like entry instead of counting

Solution

1. Step 1: Understand concurrency risks with simple set()

   Using set() without checking current value risks overwriting likes if multiple users update simultaneously.

2. Step 2: Use transaction for atomic increments

   transaction() reads current value, increments safely, and retries if data changed, ensuring correct count.

3. Step 3: Evaluate other options

   Reading once then setting risks race conditions; push() adds entries but does not increment counter directly.

4. Final Answer:

   Use ref.transaction(currentLikes => (currentLikes || 0) + 1) to increment safely -> Option A

5. Quick Check:

   Safe counter update = transaction() increment [OK]

Hint: Use transaction() with (current || 0) + 1 for safe counters [OK]

Common Mistakes:

• Using set() without concurrency control
• Reading once then setting causing race conditions
• Confusing push() with incrementing counters