Cost optimization (read/write reduction) in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Firestore Read Costs

You have a Firestore collection with 1000 documents. You run a query that returns 10 documents. How many document reads will be billed for this query?

A 1 document read

B 1000 document reads

C 10 document reads

D 0 document reads

💡 Hint

Think about how Firestore charges for queries based on documents returned, not total documents in the collection.

Firestore charges for each document returned by a query. Since 10 documents are returned, 10 document reads are billed.

❓ Architecture

intermediate

Improving Firestore Write Performance with Batched Writes

You need to update 50 documents in Firestore. Which approach reduces network calls and improves performance?

A Update each document individually with separate write calls

B Read all documents first, then update them one by one

C Delete and recreate the entire collection

D Use a batched write to update all 50 documents in one operation

💡 Hint

Consider how Firestore handles batched writes and network calls.

Batched writes group multiple updates into a single atomic operation, reducing network overhead and improving performance, though write costs per document remain the same.

❓ security

advanced

Minimizing Unnecessary Firestore Reads with Security Rules

You want to prevent users from reading documents they shouldn't access to reduce unnecessary read costs. Which security rule snippet correctly restricts reads to only documents where the user's UID matches the document's owner field?

Firebase

match /documents/{docId} {
  allow read: if request.auth.uid == resource.data.owner;
}

A allow read: if request.auth.uid == resource.data.owner;

B allow read: if request.auth.uid != resource.data.owner;

C allow read: if true;

D allow read: if request.auth.uid == null;

💡 Hint

Think about how to restrict access to only authorized users.

Option A allows reads only if the authenticated user's UID matches the document's owner field, preventing unauthorized reads and reducing costs.

🧠 Conceptual

advanced

Optimizing Firestore Data Structure for Read Efficiency

You have a Firestore app where users frequently read profile data and their recent activity. Which data structure approach reduces read operations and costs?

A Denormalize recent activity data inside the user profile document

B Store profile and recent activity in separate collections and read them separately

C Embed recent activity as a subcollection inside each user profile document

D Store all recent activity in a global collection and query by user ID

💡 Hint

Consider how denormalization can reduce the number of reads.

Denormalizing recent activity inside the user profile document allows fetching all needed data in a single read, reducing read operations and costs.

✅ Best Practice

expert

Implementing Client-side Caching to Reduce Firestore Reads

You want to minimize Firestore read costs by caching data on the client side. Which approach best balances data freshness and cost savings?

A Disable caching and always fetch fresh data from Firestore

B Use Firestore's offline persistence with periodic manual refreshes

C Cache data indefinitely on the client and never refresh

D Cache data only in memory and clear cache on every app restart

💡 Hint

Think about how Firestore's offline persistence works and how to keep data reasonably fresh.

Firestore's offline persistence caches data locally and syncs changes automatically. Periodic manual refreshes ensure data freshness while reducing read costs.

Practice

1. Which practice helps reduce Firebase costs by minimizing the number of document reads?

easy

A. Use separate writes for each field update

B. Write data multiple times to ensure consistency

C. Read data once instead of using continuous listeners

D. Always overwrite entire documents on update

Solution

1. Step 1: Understand Firebase read costs

   Firebase charges for each document read. Continuous listeners keep reading data repeatedly, increasing costs.

2. Step 2: Choose cost-saving read method

   Reading data once fetches the document a single time, reducing read operations and costs.

3. Final Answer:

   Read data once instead of using continuous listeners -> Option C

4. Quick Check:

   Minimize reads = Read once [OK]

Hint: Read once, avoid continuous listeners to save costs [OK]

Common Mistakes:

• Thinking continuous listeners cost less
• Assuming multiple writes reduce costs
• Overwriting entire documents unnecessarily

2. Which Firebase syntax correctly updates only specific fields without overwriting the entire document?

easy

A. db.collection('users').doc('abc').set({age: 30}, {merge: true})

B. db.collection('users').doc('abc').set({age: 30})

C. db.collection('users').doc('abc').update({age: 30}, {merge: true})

D. db.collection('users').doc('abc').set({age: 30}, {overwrite: false})

Solution

1. Step 1: Identify update methods in Firebase

   Using set() with {merge: true} updates only specified fields without overwriting the whole document.

2. Step 2: Check options for correctness

   db.collection('users').doc('abc').set({age: 30}, {merge: true}) uses set() with merge: true, which is the correct syntax for partial updates.

3. Final Answer:

   db.collection('users').doc('abc').set({age: 30}, {merge: true}) -> Option A

4. Quick Check:

   Partial update = set with merge true [OK]

Hint: Use set with {merge: true} to update fields only [OK]

Common Mistakes:

• Using set without merge overwrites entire document
• Using update() with invalid merge option
• Using invalid option {overwrite: false}

3. What is the effect of this Firebase code snippet on write operations?

const batch = db.batch();
batch.set(db.collection('users').doc('a'), {name: 'Alice'});
batch.set(db.collection('users').doc('b'), {name: 'Bob'});
batch.commit();

medium

A. Two separate write operations are charged

B. One combined write operation is charged

C. No write operations are charged until batch.commit() is called

D. Writes are charged only if documents exist

Solution

1. Step 1: Understand batch writes in Firebase

   Batch writes group multiple writes to execute atomically but each write counts as a separate operation for billing.

2. Step 2: Count write operations in the snippet

   Two set calls inside the batch mean two write operations charged when commit() runs.

3. Final Answer:

   Two separate write operations are charged -> Option A

4. Quick Check:

   Batch writes count each write separately [OK]

Hint: Batch groups writes but charges per write [OK]

Common Mistakes:

• Thinking batch commit charges only once
• Assuming writes are free before commit
• Believing writes charge only if doc exists

4. You want to update a user's email without overwriting other fields, but your code overwrites the entire document. What is the error?

db.collection('users').doc('user1').set({email: '[e-mail]'});

medium

A. Using update() instead of set()

B. Email field name is invalid

C. Document path is incorrect

D. Missing {merge: true} option in set()

Solution

1. Step 1: Identify why entire document is overwritten

   Using set() without {merge: true} replaces the whole document, causing data loss.

2. Step 2: Fix the code to update only one field

   Add {merge: true} to set() to update only the email field without overwriting others.

3. Final Answer:

   Missing {merge: true} option in set() -> Option D

4. Quick Check:

   Partial update needs merge true [OK]

Hint: Add {merge: true} to set() to avoid overwriting [OK]

Common Mistakes:

• Using set() without merge option
• Confusing update() and set() usage
• Assuming field names cause overwrite

5. You want to reduce Firebase costs by minimizing writes when updating user profiles. Which approach is best to update multiple fields efficiently without overwriting existing data?

hard

A. Use multiple separate set() calls without merge option

B. Use a batch write with set() and merge: true for all updates

C. Use update() for each field separately in different calls

D. Overwrite entire document with set() each time

Solution

1. Step 1: Understand cost impact of writes

   Each write operation costs money. Multiple separate writes increase cost and risk overwriting data.

2. Step 2: Choose efficient update method

   Batch writes combine multiple updates into one commit, reducing network overhead. Using set() with {merge: true} updates only needed fields without overwriting.

3. Final Answer:

   Use a batch write with set() and merge: true for all updates -> Option B

4. Quick Check:

   Batch + merge = efficient partial updates [OK]

Hint: Batch writes with merge true save cost and data [OK]

Common Mistakes:

• Overwriting entire documents unnecessarily
• Using many separate update calls
• Ignoring batch writes for multiple updates