Cost optimization (read/write reduction) in Firebase - Step-by-Step Execution

Process Flow - Cost optimization (read/write reduction)

Start: App needs data

↓

Check cache/local data

Yes↓

Use cached data - No read

↓

Update UI

↓

User changes data?

Yes↓

Batch writes or debounce

↓

Write to Firebase

↓

Update cache/local

↓

End

This flow shows how to reduce Firebase reads by using cache and reduce writes by batching or debouncing user changes.

Execution Sample

Firebase

const cache = {};

function getData(key) {
  if (cache[key]) return cache[key];
  const data = firebase.read(key);
  cache[key] = data;
  return data;
}

function updateData(key, value) {
  debounceWrite(key, value);
}

This code reads data from cache if available, otherwise from Firebase, and writes data with debounce to reduce writes.

Process Table

Step	Action	Cache State	Firebase Reads	Firebase Writes	Result
1	Request data 'user1'	{}	No	No	Cache miss, triggers Firebase read
2	Firebase returns data for 'user1'	{'user1': data1}	Yes	No	Cache updated with data1
3	Request data 'user1' again	{'user1': data1}	No	No	Cache hit, no Firebase read
4	User updates 'user1' data	{'user1': data1}	No	No	Write debounced, no immediate Firebase write
5	Debounce timer triggers write	{'user1': data1}	No	Yes	Firebase write occurs
6	Cache updated with new data	{'user1': newData}	No	No	Cache reflects latest data
7	Request data 'user1' after update	{'user1': newData}	No	No	Cache hit, no Firebase read
8	End	{'user1': newData}	No	No	Optimized reads and writes

💡 Execution ends after data is cached and writes are debounced to minimize Firebase operations.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
cache	{}	{'user1': data1}	{'user1': data1}	{'user1': newData}	{'user1': newData}
Firebase Reads	0	1	1	1	1
Firebase Writes	0	0	0	1	1

Key Moments - 3 Insights

Why does the second request for 'user1' not cause a Firebase read?

Because the data is already stored in the cache from step 2, so the code returns cached data without reading Firebase again (see step 3 in execution_table).

How does debouncing reduce the number of Firebase writes?

Debouncing delays the write operation until the user stops making changes, so multiple quick updates result in a single Firebase write (see steps 4 and 5 in execution_table).

Why is the cache updated after the Firebase write?

Updating the cache after writing ensures the app has the latest data locally, preventing unnecessary reads (see step 6 in execution_table).

Visual Quiz - 3 Questions

Look at the execution table, at which step does the first Firebase read occur?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Check the 'Firebase Reads' column in execution_table rows 1 and 2.

According to variable_tracker, how many Firebase writes happen by the end?

A 0

B 1

C 2

D 3

💡 Hint

Look at the 'Firebase Writes' row in variable_tracker at the 'Final' column.

If caching was not used, what would change in the execution_table?

A More Firebase reads on repeated data requests

B More Firebase writes on updates

C No Firebase reads at all

D No Firebase writes at all

💡 Hint

Consider the 'Cache State' and 'Firebase Reads' columns in execution_table.

Concept Snapshot

Cost optimization in Firebase means reducing reads and writes.
Use local cache to avoid repeated reads.
Use debounce or batch writes to reduce write frequency.
This saves money and improves app speed.
Always update cache after writes to keep data fresh.

Full Transcript

This lesson shows how to save money using Firebase by reducing how often the app reads and writes data. First, the app checks if data is in a local cache. If yes, it uses that data without reading Firebase again. If no, it reads from Firebase and stores it in cache. When the user changes data, the app waits briefly (debounce) before writing to Firebase, so many quick changes become one write. After writing, the cache updates to keep data fresh. This way, the app uses fewer Firebase reads and writes, saving cost and improving speed.

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