Optimistic concurrency in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does Firebase handle optimistic concurrency with document updates?

Consider a Firebase Firestore document that multiple clients try to update simultaneously using optimistic concurrency. What happens if two clients read the same document version and try to update it at the same time?

A The first update succeeds, and the second update fails with a version conflict error.

B Both updates succeed, and the last write overwrites the first without any error.

C Firebase queues the updates and applies them sequentially without conflicts.

D Firebase rejects both updates to prevent any conflict.

💡 Hint

Think about how Firestore uses document versions or update timestamps to detect conflicts.

Firebase Firestore uses optimistic concurrency by checking the document's version or update timestamp. If a client tries to update a document that has changed since it was read, the update fails with a conflict error, ensuring data consistency.

❓ Architecture

intermediate

Designing a Firebase app to handle optimistic concurrency conflicts

You are building a collaborative note-taking app using Firebase Firestore. Multiple users can edit the same note at the same time. Which design approach best handles optimistic concurrency conflicts?

A Store all edits in a queue and apply them one by one on the server.

B Allow all writes without checks and rely on Firestore to merge changes automatically.

C Lock the note document for editing by one user at a time using a separate lock field.

D Use Firestore transactions to read the note, apply changes, and commit only if the note version is unchanged.

💡 Hint

Consider how Firestore transactions help maintain data integrity during concurrent updates.

Firestore transactions read the current document state and apply updates only if the document has not changed. This approach prevents overwriting concurrent changes and handles optimistic concurrency effectively.

❓ security

advanced

Security implications of optimistic concurrency in Firebase

Which security risk is most relevant when using optimistic concurrency control in Firebase Firestore?

A Data is encrypted with weak keys during optimistic concurrency updates.

B Optimistic concurrency allows unauthorized users to bypass Firestore security rules.

C A malicious client could repeatedly attempt conflicting updates to cause denial of service.

D Firestore transactions expose user credentials during conflict resolution.

💡 Hint

Think about how repeated failed updates might affect system availability.

Repeated conflicting update attempts by a malicious client can overload Firestore with failed transactions, potentially causing denial of service. Proper rate limiting and security rules help mitigate this risk.

✅ Best Practice

advanced

Best practice for retrying failed optimistic concurrency updates in Firebase

When a Firestore update fails due to optimistic concurrency conflict, what is the best practice to handle the retry?

A Fetch the latest document state, merge changes if needed, then retry the update.

B Use a fixed delay and retry the update blindly multiple times.

C Discard the update and notify the user to refresh the app manually.

D Immediately retry the same update without fetching the latest document.

💡 Hint

Consider how to keep data consistent when retrying after a conflict.

Fetching the latest document state before retrying ensures that updates are applied on the most recent data, preventing repeated conflicts and data loss.

🧠 Conceptual

expert

Why does Firebase Firestore prefer optimistic concurrency over pessimistic locking?

Firebase Firestore uses optimistic concurrency control instead of pessimistic locking. What is the main reason for this choice?

A Optimistic concurrency eliminates all conflicts automatically without retries.

B Optimistic concurrency scales better in distributed environments with many clients.

C Pessimistic locking is not supported by Firestore's NoSQL data model.

D Pessimistic locking requires complex user authentication mechanisms.

💡 Hint

Think about how Firestore is designed to work with many users and devices worldwide.

Optimistic concurrency allows Firestore to handle many concurrent users without locking resources, which improves scalability and performance in distributed systems.

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