Why write patterns affect consistency in Firebase - Performance Analysis
When using Firebase, how you write data affects how fast and reliably your app stays in sync.
We want to see how different write patterns change the work Firebase does behind the scenes.
Analyze the time complexity of writing multiple user profiles one by one.
const db = firebase.firestore();
const users = [{id: 'u1', name: 'Alice'}, {id: 'u2', name: 'Bob'}, /* more users */];
for (const user of users) {
db.collection('users').doc(user.id).set({ name: user.name });
}
This code writes each user profile separately to the database.
Look at what repeats as the input grows.
- Primary operation: One write call per user document.
- How many times: Once for each user in the list.
Each user causes a separate write, so more users mean more writes.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 writes |
| 100 | 100 writes |
| 1000 | 1000 writes |
Pattern observation: The number of writes grows directly with the number of users.
Time Complexity: O(n)
This means the work grows in a straight line as you add more users to write.
[X] Wrong: "Writing many documents one by one is just as fast as writing them all at once."
[OK] Correct: Each separate write sends a request and waits for confirmation, so doing many writes separately takes more time and can cause delays in consistency.
Understanding how write patterns affect consistency helps you design apps that stay reliable and fast as they grow.
What if we used a batch write to send all user updates at once? How would the time complexity change?
Practice
Solution
Step 1: Understand the role of write patterns
Write patterns determine how data is updated and saved in Firebase.Step 2: Connect write patterns to consistency
They control how consistent the data remains after updates.Final Answer:
How data updates affect consistency -> Option AQuick Check:
Write pattern = data consistency control [OK]
- Confusing write patterns with UI design
- Thinking write patterns affect network speed
- Assuming write patterns change app colors
Solution
Step 1: Identify the method that merges data
set() with merge:true updates fields without replacing the entire document.Step 2: Compare with other methods
update() changes fields but fails if document missing; delete() removes data; get() reads data.Final Answer:
set() with merge option -> Option AQuick Check:
Merge option in set() = partial update [OK]
- Using update() without checking document existence
- Confusing delete() with update()
- Thinking get() writes data
const docRef = firestore.doc('users/user1');
firestore.runTransaction(async (transaction) => {
const doc = await transaction.get(docRef);
const newCount = (doc.data().count || 0) + 1;
transaction.update(docRef, { count: newCount });
});What is the main benefit of using this transaction pattern?
Solution
Step 1: Analyze the transaction usage
The code reads the current count and updates it inside a transaction.Step 2: Understand transaction benefits
Transactions prevent conflicts by retrying if data changes during update, ensuring correct increments.Final Answer:
It ensures the count increments correctly even with simultaneous updates -> Option DQuick Check:
Transaction = safe concurrent updates [OK]
- Thinking transaction deletes data
- Assuming transaction only reads data
- Believing transaction overwrites blindly
firestore.doc('items/item1').update({ stock: 10 });But sometimes it fails with 'Document does not exist' error. What is the best fix?
Solution
Step 1: Understand update() behavior
update() fails if the document does not exist.Step 2: Use set() with merge:true to create or update
set() with merge:true creates the document if missing and updates fields safely.Final Answer:
Use set() with merge:true instead of update() -> Option CQuick Check:
set() with merge avoids missing document errors [OK]
- Trying to delete before update unnecessarily
- Using get() which only reads data
- Ignoring errors without fixing cause
Solution
Step 1: Identify atomic update needs
Updating profile and incrementing count must happen together to avoid partial updates.Step 2: Choose transaction for atomicity
Transactions ensure all changes succeed or none do, keeping data consistent.Step 3: Reject separate writes or deletes
Separate set() calls risk partial updates; delete() resets data unnecessarily.Final Answer:
Use a transaction to read, update profile fields, and increment count together -> Option BQuick Check:
Transaction = atomic multi-field update [OK]
- Updating fields separately risking inconsistency
- Ignoring count increment
- Deleting data before update
Ready to prove it?
Pass the test and this pattern moves unknown
