Cost optimization (read/write reduction) in Firebase - Mini Project: Build & Apply

Cost Optimization with Firebase Read/Write Reduction

📖 Scenario: You are managing a Firebase Realtime Database for a small online store. You want to reduce the number of reads and writes to save costs while keeping the data accurate and up to date.

🎯 Goal: Build a Firebase Realtime Database structure and rules that minimize unnecessary reads and writes by using data denormalization and efficient queries.

📋 What You'll Learn

Create a Firebase Realtime Database structure with products and orders

Add a configuration variable to limit the number of product details fetched

Write a query to fetch only the top N products based on the configuration

Add security rules to allow read/write only to necessary paths

💡 Why This Matters

🌍 Real World

This project simulates managing a Firebase database for an online store where cost control is important by reducing unnecessary database operations.

💼 Career

Understanding how to optimize Firebase reads and writes is valuable for roles like Cloud Engineer, Backend Developer, and DevOps Specialist working with serverless databases.

1

Create initial Firebase data structure

Create a Firebase Realtime Database JSON structure with a products node containing exactly these three products: product1 with name "Laptop" and price 1200, product2 with name "Phone" and price 800, and product3 with name "Tablet" and price 600.

Firebase

{
  "products": {
    // Your code here
  }
}

Hint

Use a JSON object with a products key and add three product objects inside.

2

Add configuration variable for product fetch limit

Add a configuration variable called maxProductsToFetch and set it to 2 inside a new config node in the Firebase JSON structure.

Firebase

{
  "products": {
    "product1": {"name": "Laptop", "price": 1200},
    "product2": {"name": "Phone", "price": 800},
    "product3": {"name": "Tablet", "price": 600}
  },
  "config": {
    // Your code here
  }
}

Hint

Add a new config object with the variable inside.

3

Write a query to fetch limited products

Write a Firebase Realtime Database query in JSON format under a new queries node that fetches products ordered by price descending and limits the results to the value of maxProductsToFetch. Name this query topProducts.

Firebase

{
  "products": {
    "product1": {"name": "Laptop", "price": 1200},
    "product2": {"name": "Phone", "price": 800},
    "product3": {"name": "Tablet", "price": 600}
  },
  "config": {
    "maxProductsToFetch": 2
  },
  "queries": {
    // Your code here
  }
}

Hint

Use orderBy with price and limitToLast with the config value.

4

Add Firebase security rules for read/write access

Add Firebase Realtime Database security rules that allow read access only to the products and config nodes, and allow write access only to the config node. Deny all other access.

Firebase

{
  "rules": {
    // Your code here
  }
}

Hint

Set .read and .write rules explicitly for each node.

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