Query optimization in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Firestore Query Index Requirements

You have a Firestore collection with documents containing fields: age (number), city (string), and status (string). You run this query:
collection.where('age', '>', 25).where('city', '==', 'Seattle').orderBy('status')
What will happen when you run this query without any additional setup?

A The query fails with an error asking to create a composite index.

B The query runs successfully without any errors.

C The query returns documents but ignores the orderBy clause.

D The query returns documents but only filters by age.

💡 Hint

Firestore requires composite indexes for queries with multiple where filters and orderBy on different fields.

Firestore needs a composite index when you combine multiple where filters with an orderBy on a different field. Without it, the query fails and prompts you to create the index.

❓ Architecture

intermediate

Optimizing Firestore Queries for Large Collections

You have a Firestore collection with millions of documents. You want to efficiently fetch documents where status is 'active' and order them by createdAt descending. Which approach is best to optimize query performance?

A Use multiple queries for each status value and merge results in the app.

B Use a query with where('status', '==', 'active') and orderBy('createdAt', 'desc') with a composite index on status and createdAt.

C Use orderBy('createdAt', 'desc') only and filter status after fetching.

D Fetch all documents and filter 'active' status in your application code.

💡 Hint

Filtering and ordering in the query with proper indexes is more efficient than client-side filtering.

Using a composite index on status and createdAt allows Firestore to efficiently filter and order documents server-side, reducing data transfer and latency.

❓ security

advanced

Securing Firestore Queries with Rules and Indexes

You want to allow users to query their own orders by userId and filter by orderStatus. You create a composite index on userId and orderStatus. Which Firestore security rule best ensures users can only query their own orders?

A allow read: if request.auth.token.admin == true;

B allow read: if request.auth.uid != null;

C allow read: if resource.data.orderStatus == 'completed';

D allow read: if request.auth.uid == resource.data.userId;

💡 Hint

Security rules should restrict access based on user identity matching document fields.

Rule A restricts reads to documents where the userId matches the authenticated user's ID, ensuring users only access their own orders.

✅ Best Practice

advanced

Reducing Firestore Query Costs with Pagination

You have a Firestore query that returns thousands of documents. To reduce cost and improve performance, what is the best practice to paginate results?

A Use offset() to skip documents and limit() to fetch pages.

B Fetch all documents at once and slice the results in the client.

C Use limit() with startAfter() or startAt() cursors to fetch pages incrementally.

D Run multiple queries with different where filters to split data.

💡 Hint

Firestore charges for documents read, so fetching only needed documents is best.

Using limit() with cursors like startAfter() fetches only the needed documents per page, reducing reads and cost. Using offset() still reads skipped documents, increasing cost.

🧠 Conceptual

expert

Analyzing Firestore Query Execution Behavior

Consider a Firestore collection with documents having fields: category, price, and rating. You run this query:
collection.where('category', '==', 'books').orderBy('price').orderBy('rating')
Which statement best describes how Firestore executes this query?

A Firestore uses a composite index on category, price, and rating to efficiently filter and order results.

B Firestore orders by price only and ignores the rating orderBy clause.

C Firestore filters by category first, then orders by price and rating without needing an index.

D Firestore requires separate queries for price and rating ordering.

💡 Hint

Multiple orderBy clauses require a composite index covering all fields in order.

Firestore requires a composite index that includes all where and orderBy fields in the correct order to execute such queries efficiently.