85 Firebase Interview Questions and Answers (2026)

Firestore organizes data into documents (sets of typed key/value fields) that live inside collections; documents can contain subcollections, forming a tree. Unlike relational tables, there is no fixed schema and no server-side joins.

• Core building blocks:

  • Document: a record with fields (string, number, map, array, reference, etc.), max 1 MiB.

  • Collection: a container of documents (analogous to a table, but schemaless).

  • Subcollection: a collection nested under a document, enabling hierarchy.

• Differences from relational schema:

  • No enforced schema: documents in the same collection can have different fields.

  • No joins: you denormalize/duplicate data or do client-side lookups instead of normalizing.

  • Queries are shallow: fetching a document does not auto-fetch its subcollections.

  • Modeling follows access patterns (how you read), not normalization rules.

Serverless in Firebase means you write application logic and data rules without provisioning, patching, or scaling servers: Google manages the infrastructure and scales it automatically, and you pay for usage rather than idle capacity.

• What it means in practice:

  • No servers to manage: capacity, scaling, and availability are handled by the platform.

  • Event/usage-driven billing: you pay per invocation, read/write, or bandwidth, scaling to zero when idle.

• Serverless Firebase pieces:

  • Cloud Functions: run backend code on events (HTTP, Firestore triggers, auth events).

  • Firestore/RTDB: managed databases clients can access directly, secured by Security Rules instead of a backend tier.

  • Authentication, Hosting, Storage: managed services with no infrastructure to run.

• Trade-offs: Cold starts on functions, vendor lock-in, and less control over the runtime environment.

Firebase is Google's Backend-as-a-Service (BaaS) platform: a suite of hosted tools that let you build, run, and scale apps without managing your own servers, covering data, auth, hosting, and analytics behind client SDKs.

• Build / backend services:

  • Authentication: managed sign-in (email, phone, OAuth providers).

  • Cloud Firestore and Realtime Database: NoSQL document/JSON stores with realtime sync.

  • Cloud Storage: file/blob storage.

  • Cloud Functions: serverless event-driven and HTTP backend code.

  • Hosting: static and dynamic web hosting on a global CDN.

• Quality / release: Crashlytics, Performance Monitoring, Test Lab, and App Distribution.

• Engage / grow: Cloud Messaging (FCM), Remote Config, A/B Testing, and Google Analytics.

• Unifying idea: Clients talk directly to services via SDKs, with Security Rules enforcing access, so much of the traditional backend layer disappears.

Firebase Security Rules are server-side authorization logic that Google evaluates on its backend for every request to Firestore, Realtime Database, or Cloud Storage. They are not client code: even though clients call the database directly, the rules run on Firebase's servers and cannot be bypassed by a tampered client.

• Where they execute: Always on Google's servers, before any read/write is allowed. The client SDK just sends the request; the server admits or denies it.

• What they do:

  • Match request paths and allow operations (read, write, get, list, create, update, delete) based on conditions.

  • Use context like request.auth (who), request.resource.data (incoming data), and resource.data (existing data).

• Key principle:

  • They are authorization, not validation help for the UI: they are your real security boundary, so never rely on client checks alone.

  • Rules don't filter data; a query must be guaranteed by the rules to only request allowed documents or it fails.

The Firebase API key is not a secret: it only identifies which Firebase project your app talks to, it does not grant access. Authorization is decided by Security Rules and Auth, so exposing the key changes nothing about who can read or write.

• It's an identifier, not a credential: It routes requests to your project; it carries no permissions by itself.

• Access is gated elsewhere: Data access is controlled by Security Rules and authenticated tokens, not by possession of the key.

• Still worth restricting: Use key restrictions (HTTP referrers, allowed APIs) and App Check to limit abuse and quota theft, even though the key alone is harmless.

Authentication answers "who are you?" (verifying identity via Firebase Authentication), while authorization answers "what are you allowed to do?" (enforced by Security Rules, custom claims, or your own backend logic).

• Authentication:

  • Handled by Firebase Auth: sign-in providers, token issuance, and the resulting uid.

  • Produces a verifiable ID token proving identity.

• Authorization:

  • Enforced in Firestore/Realtime Database/Storage Security Rules using request.auth.

  • Role-based access is driven by custom claims set via the Admin SDK and read from the token.

• Why the split matters:

  • A user can be authenticated but still unauthorized for a specific document or action.

  • Firebase gives you identity; you must explicitly write the permission logic.

They differ in how identity is proven and what user data and friction they involve: Email/Password is self-managed credentials, Google is federated OAuth with low friction and pre-verified identity, and Phone uses SMS OTP tied to a device number; the choice balances UX, trust, cost, and your audience.

• Email/Password:

  • Full control and no provider dependency, but you must handle resets, verification, and password security.

  • Best when users expect a classic account or you can't rely on social logins.

• Google (OAuth):

  • One-tap, no password to manage, email pre-verified, often higher conversion.

  • Adds dependency on the provider and works best where users have Google accounts.

• Phone:

  • Great for mobile-first or markets where phone is the primary identity; no password needed.

  • Costs money per SMS, vulnerable to SIM-swap, and needs reCAPTCHA/App Check against abuse.

• Factors influencing choice:

  • Audience and region (Google adoption, smartphone reliance).

  • Friction vs. control, security needs, and cost (SMS fees).

  • Often offer several and link them to one uid so users can choose.

A notification message is a display message the FCM SDK shows automatically, while a data message is a custom key-value payload delivered to your app code for you to handle. The big difference is who handles it and whether it arrives when the app is in the background.

• Notification message:

  • Contains a notification key (title, body); the SDK renders it to the system tray automatically when the app is backgrounded.

  • Your callback only runs if the user taps it (or if the app is in foreground).

• Data message:

  • Contains only a data key with custom fields; never auto-displayed.

  • Always delivered to your handler (e.g. onMessageReceived) so you control behavior, including building your own notification.

• Combined payload: If you include both, backgrounded apps show the notification via the tray and the data arrives in the intent only on tap, which often surprises developers.

• Rule of thumb: use notification messages for simple alerts, data messages (data-only) when you need guaranteed custom handling and full control.

Firebase Remote Config is a cloud-hosted key-value store of parameters your app fetches at runtime, letting you change app behavior and appearance without shipping a new build. You use it whenever you want to tune, toggle, or target features dynamically.

• How it works:

  • You define parameters and default values in-app; the server values override them after a fetch and activate.

  • Values are cached, and fetches are throttled (a minimum fetch interval) to limit network use.

• Conditions/targeting: Serve different values by app version, platform, country, user audience, or random percentage.

• When to use it: Feature flags and kill switches, gradual rollouts, A/B tests, seasonal theming, or backend-driven config like API endpoints and limits.

• Caveat: not for secrets (values are readable by clients) and not a real-time database (changes apply on next fetch/activate).

Standard logging writes free-form text locally or to a log service for you to read line by line, while Crashlytics is a crash reporting system that captures structured, grouped, symbolicated crash reports from real users in the field and surfaces them in a dashboard with prioritization.

• Aggregation and grouping: Crashlytics clusters thousands of identical crashes into a single issue with counts and affected users; logs are just sequential lines.

• Rich context:

  • Captures full stack traces, device model, OS, app version, and breadcrumbs automatically.

  • Symbolicates native/obfuscated traces so they are human-readable.

• Remote and real-time: Reports come from production devices you cannot attach a debugger to, with alerting on spikes and new issues.

• They complement each other: Use log() and custom keys to attach breadcrumbs that appear inside a crash report, combining logging detail with crash aggregation.

Firebase Cloud Storage is an object storage service for large unstructured files (images, video, audio, documents), backed by Google Cloud Storage. Firestore, by contrast, is a NoSQL document database for structured, queryable data. You use them together: store the file in Storage and store its metadata and download URL in Firestore.

• What each is built for:

  • Cloud Storage: blobs (binary files), often large, served via download URLs with resumable upload/download.

  • Firestore: JSON-like documents organized in collections, optimized for queries, indexing, and realtime updates.

• Querying capability: Firestore lets you filter, sort, and paginate; Storage has no query engine, you fetch by path.

• Cost and limits: Firestore documents are capped at 1 MiB and billed per read/write, so storing big files there is wrong and expensive; Storage bills on bytes stored and transferred.

• Common pattern: Upload the file to Storage, then save its URL plus metadata (owner, size, timestamp) as a Firestore document for querying.

Spark is the free tier with fixed daily/monthly quotas and no billing account; Blaze is pay-as-you-go, including a free allotment but charging beyond it. Several services and any external networking require Blaze because they can incur outbound or compute cost.

• Spark (free):

  • No credit card; hard quota caps so you can never be billed.

  • Good for prototypes and learning; usage simply stops when limits are hit.

• Blaze (pay-as-you-go):

  • Requires a billing account; includes the same free quotas, then charges per usage above them.

  • Scales for production; set budget alerts to avoid surprise bills.

• Features that require Blaze:

  • Cloud Functions deployment (modern runtimes) needs Blaze.

  • Outbound networking to non-Google APIs (e.g. calling a third-party HTTP endpoint) requires Blaze.

  • Higher-scale or extended-quota usage of Firestore, Storage, Hosting, and other paid integrations.

• Key takeaway: Spark protects against cost but blocks production features; Blaze unlocks scale and integrations but needs budget monitoring.

Both are NoSQL cloud databases, but Realtime Database is one large JSON tree while Firestore is a structured collection of documents; the difference drives how you query, scale, and model data.

• Data model:

  • Realtime Database stores everything as one giant JSON tree (nodes within nodes).

  • Firestore stores data as documents (key/value with typed fields) grouped into collections, with subcollections for hierarchy.

• Querying:

  • RTDB queries are limited: you sort/filter on a single property and fetch deep, often pulling whole subtrees.

  • Firestore supports indexed compound queries with multiple filters, and a query never downloads data you didn't ask for.

• Scaling:

  • RTDB scales by throughput/connections and may require sharding across multiple databases.

  • Firestore scales horizontally and automatically, billed mostly per document read/write.

• Latency vs. richness:

  • RTDB offers extremely low-latency syncing, ideal for fast presence/state.

  • Firestore trades a bit of latency for richer queries and strong consistency.

Choose Firestore as the default for most apps (richer queries, better scaling, structured data) and pick Realtime Database when you need the absolute lowest-latency syncing of simple, high-frequency state.

• Choose Firestore when:

  • You need complex queries, multiple filters, or sorting on several fields.

  • Data is naturally hierarchical or document-shaped and may grow large.

  • You want automatic multi-region scaling and strong consistency.

• Choose Realtime Database when:

  • You sync small, frequently changing state (presence, live cursors, simple chat) and need the lowest latency.

  • Your data is simple and you don't need rich querying.

  • You want cheaper, throughput-based billing for very high update frequency.

• Common pattern: use both, RTDB for presence/ephemeral state and Firestore for the core data model.

Realtime Database scales vertically against a single database instance with hard ceilings on simultaneous connections and write throughput, so heavy load requires manual sharding; Firestore scales horizontally and automatically with no manual partitioning.

• Realtime Database limits:

  • Bounded by simultaneous connections (~200k) and writes per second per instance.

  • To go beyond limits you shard data across multiple RTDB instances and route in the client/server yourself.

  • Throughput is the bottleneck, not data size.

• Firestore scaling:

  • Scales automatically and horizontally; query performance depends on result set size, not total dataset size.

  • No manual sharding needed for normal growth.

• Firestore's caveat: The 500 writes/sec per document and ~1 write/sec sustained limit; avoid monotonically increasing index values (hotspotting).

Firebase Extensions are prepackaged, configurable solutions (built on Cloud Functions) that solve a common task with no code, such as resizing images, syncing to BigQuery, or sending email. Use one when a maintained, official solution already covers your need instead of building and maintaining your own.

• What they are:

  • Reusable bundles of functions, IAM roles, and config you install into your project and parameterize (no code to write).

  • Examples: Resize Images, Trigger Email, Stream Firestore to BigQuery.

• Use an Extension when:

  • The task is common and an official/partner extension exists.

  • You want faster setup and less maintenance burden (updates handled upstream).

• Write your own Function when:

  • Logic is custom or business-specific, or you need fine-grained control over behavior, triggers, and dependencies.

  • You need to combine many steps that no extension models cleanly.

• Trade-off: Extensions trade flexibility for speed and reliability; they still bill as normal Cloud Functions resources.

In a Security Rule, request.auth is about who is making the request (the authenticated user and their token), while resource.data is the data already stored in the document being accessed. You use request.auth for identity/authorization and resource.data to make decisions based on the document's current state.

• request.auth:

  • The caller's auth context: request.auth.uid, token claims, etc. null if unauthenticated.

  • Use it to check identity, ownership, or roles via custom claims.

• resource.data:

  • The existing document's fields (before the write). On a write, the incoming data is request.resource.data.

  • Use it to gate on stored state, e.g. who owns the doc or whether a field equals a value.

• Combined in practice:

  • Ownership checks compare them: request.auth.uid == resource.data.ownerId.

  • Validation of edits compares request.resource.data against resource.data (e.g. don't let ownerId change).

Custom Claims are key-value attributes you attach to a user's Auth token (via the Admin SDK) to represent roles or permissions. They travel inside the ID token, so Security Rules and backends can authorize a user without an extra database read, making them ideal for access control.

• How they work:

  • Set server-side: admin.auth().setCustomUserClaims(uid, { role: 'admin' }).

  • Available in rules as request.auth.token.role and on the client after a token refresh.

• Use claims when:

  • You need fast, frequent authorization checks in Security Rules without an extra get() lookup (which costs a read and latency).

  • Roles are coarse, stable, and small (claims are limited to ~1000 bytes).

• Use a Firestore doc when:

  • Roles change often or need to take effect instantly (claims only update when the token refreshes, up to ~1 hour).

  • Permissions are complex, large, or you want to query/list users by role.

• Trade-off summary: Claims: cheaper checks, but propagation lag and size limits. Firestore: flexible and instant, but adds reads to each rule check.

Firebase App Check protects your backend resources from abuse by verifying that incoming requests come from your genuine, untampered app and not from bots, scripts, or stolen API keys. It complements (does not replace) Security Rules and Auth by answering "is this a legitimate client?" rather than "is this user allowed?".

• How it works:

  • The app uses an attestation provider (Play Integrity on Android, App Attest/DeviceCheck on Apple, reCAPTCHA on web) to obtain a token.

  • That token is sent with each request; Firebase backends verify it before serving.

• What it protects: Firestore, Realtime Database, Cloud Storage, Functions, and other resources can require valid App Check tokens.

• How it differs from Auth/Rules:

  • Auth identifies the user; Security Rules authorize the action; App Check attests the client device/app itself.

  • Use all three together for defense in depth against quota abuse, billing fraud, and data scraping.

• Rollout tip: Start in monitoring mode to measure legitimate traffic before enforcing, so you don't block real users.

You don't trust the client at all: security lives on the server in Security Rules (for Firestore/RTDB/Storage), which the database engine enforces on every request regardless of what the decompiled app sends.

• Treat the client as hostile: Anyone can read your bundle, extract keys, and craft raw API calls, so client code can never be the gatekeeper.

• Enforcement is server-side:

  • Firebase evaluates Security Rules on its backend; a write that violates them is rejected even if the SDK is bypassed.

  • Rules gate on request.auth (identity from a verified token) and validate the incoming data shape.

• Defense in depth: Combine Rules with App Check (attests the request comes from your genuine app) and Cloud Functions for sensitive logic.

Security Rules are a declarative authorization layer that runs inside the database engine on every request, whereas server-side middleware is imperative code you write and host yourself in front of the data.

• Declarative vs imperative: Rules use a purpose-built language describing what is allowed; middleware is general-purpose code with full logic flexibility.

• Always-on enforcement: Rules can't be bypassed because the SDK talks straight to the database, while middleware only protects requests that actually route through your server.

• Limited compute: Rules can read a few other documents via get()/exists() but can't call external APIs or run heavy logic; middleware can.

• When middleware still wins: Complex validation, third-party calls, or secret-keyed operations belong in Cloud Functions / your backend with the Admin SDK.

Custom Claims are key-value attributes you attach to a user's auth token from a trusted backend; they ride inside the ID token so Security Rules and your app can read a user's role without a database lookup.

• Set claims from the backend: Only the Admin SDK can call setCustomUserClaims(), so roles can't be spoofed by the client.

• Claims embed in the token: Rules read them via request.auth.token.admin, giving fast, lookup-free authorization.

• Caveats:

  • Claims refresh only when the token does (up to ~1 hour); force a refresh with getIdToken(true) for instant role changes.

  • Keep claims small (1KB limit); use them for coarse roles, not bulk data.

Use the Admin SDK in trusted server environments (Cloud Functions, your own backend) when you need privileged operations; it bypasses Security Rules entirely, so it must never run on a client.

• When to use it:

  • Privileged tasks: setting Custom Claims, minting tokens, bulk writes, server-side validation, accessing data across all users.

  • Logic that needs secrets or third-party calls that don't belong in client code.

• It has full admin access: The Admin SDK authenticates with a service account and ignores Security Rules, so you become responsible for authorization in your own code.

• Security implications:

  • Run it only in trusted environments and protect the service account key; a leaked key is total project compromise.

  • Validate inputs yourself, since no rules act as a safety net.

An HTTP trigger runs in response to a direct web request and returns a response to the caller; a background trigger like onWrite runs reactively when a Firebase/Google Cloud event occurs, with no client waiting on a response.

• HTTP triggers are invoked synchronously:

  • Created with functions.https.onRequest or onCall; you get a request and must send a response.

  • Caller-facing: used for REST endpoints, webhooks, or callable client functions.

• Background triggers are event-driven:

  • Fire on a data event: Firestore (onWrite, onCreate), Auth user creation, Storage uploads, Pub/Sub messages.

  • No HTTP response; they just process the event payload.

• Retry behavior differs:

  • HTTP failures surface to the caller and are not auto-retried.

  • Background functions can be configured to retry on failure, so they must be idempotent.

A Cloud Function is deployed once, then sits idle until a matching event arrives; the platform spins up an instance (cold start), runs your handler with the event payload, and either keeps the instance warm for reuse or tears it down.

• Deploy phase: Code is packaged and registered with its trigger binding (HTTP route, Firestore path, Pub/Sub topic, etc.).

• Trigger and instance allocation:

  • On an event, the runtime finds a warm instance or creates a new one (a cold start: container boot + your global init code runs).

  • Code outside the handler (the global scope) runs once per instance, so it's the place to init clients and reuse connections.

• Execution:

  • Your handler receives the event data and context; for async work you return a Promise so the platform knows when it's done.

  • One instance handles one request at a time (1st gen); 2nd gen can handle concurrent requests.

• Scale and teardown:

  • Concurrent events spawn more instances; idle instances are reclaimed later.

  • Background triggers may retry on failure, HTTP triggers do not.

Even for a 'thick' client that does a lot locally, Cloud Functions provide a trusted server-side place to run logic that must not live on the client: secret-keeping, validation, and privileged operations.

• Security and trust:

  • Keep API keys, third-party secrets, and admin credentials off the device.

  • Use the Admin SDK to bypass security rules safely for privileged writes.

• Trusted enforcement:

  • Server-side validation and business rules the client can't tamper with.

  • Authoritative operations like payments, sending email, or moderation.

• Centralized, cross-platform logic:

  • Write once; iOS, Android, and web share the same behavior without re-implementing it.

  • Fix or change logic by deploying a function, no app store release needed.

• Integration and reaction: Background triggers react to data changes (e.g. fan-out, denormalization) without client involvement.

Move logic to a Cloud Function when it must be trusted, secret, or coordinated across clients; keep it on the client when it's purely presentational or latency-sensitive. The tradeoff is added round-trip latency and per-invocation cost versus security and consistency.

• Move to a function when:

  • It needs secrets or admin privileges, or must be tamper-proof (validation, payments).

  • It must be consistent across platforms or react to backend events.

  • It involves heavy or sensitive third-party API calls.

• Keep on the client when:

  • It's UI logic, formatting, or optimistic updates where instant feedback matters.

  • It can run on locally cached data without a network hop.

• Latency tradeoff: A function call adds a network round trip plus possible cold-start delay versus instant local execution.

• Cost tradeoff: Client compute is free to you; functions bill per invocation, compute time, and egress, so high-frequency trivial calls add up.

A trigger firing only guarantees the event was emitted, not that your code completes: the function can fail at allocation, startup, or runtime, or be silently throttled or filtered out.

• Startup and deploy issues:

  • Code errors in the global scope or a failed/old deployment prevent the handler from running.

  • Cold start exceeds time limits, or the wrong region/trigger binding means the event never reaches it.

• Resource and quota limits:

  • Out-of-memory or CPU exhaustion kills the instance.

  • Hitting max instances, concurrency, or project quotas throttles or drops invocations.

• Runtime errors:

  • Unhandled exceptions or timeouts; for async code, not returning the Promise so it's killed mid-flight.

  • Missing IAM permissions for the resources it touches.

• Configuration and billing:

  • Billing disabled or required APIs not enabled.

  • Event filters or duplicate-suppression mean it intentionally doesn't run.

Using Cloud Functions for everything gives a serverless, uniform model but inherits their limits everywhere; using them only for specific triggers keeps them as targeted glue while heavier or stateful work lives elsewhere. The choice balances simplicity against performance and cost.

• All logic in Functions:

  • Pros: one deployment model, auto-scaling, no servers to manage, fast to ship.

  • Cons: cold starts on every path, timeouts and memory caps everywhere, no persistent connections/cache, and per-invocation cost balloons at high traffic.

  • Architectural risk: a sprawling 'function monolith' that's hard to reason about and rate-limit.

• Functions only for specific triggers:

  • Pros: use them where they shine (event reactions, lightweight endpoints) and put sustained/stateful work on Cloud Run or a dedicated backend.

  • Cons: more moving parts and multiple deployment/runtime models to maintain.

• Guiding principle: Match workload to runtime: event-driven and bursty in Functions, long-running/high-throughput in a dedicated service.

A shallow read pulls only the keys/top level of a location, while a deep read pulls an entire node and all its descendants: deep reads can drag down huge subtrees you don't need, hurting bandwidth and latency.

• Deep query (default in Realtime Database): Reading a node downloads the whole subtree under it, so a single fetch on a large parent can transfer megabytes you'll discard.

• Shallow query: REST supports shallow=true to return just the child keys (as booleans), letting you discover structure without downloading data.

• Why it matters for performance:

  • Realtime Database has no field-level projection: you pay for everything under the path you read.

  • This drives data modeling: flatten/denormalize and split large nodes so reads stay cheap.

• Firestore contrast: Firestore reads a document without its subcollections by default, so it is naturally "shallow" at the document boundary.

A composite index in Firestore is an index built over multiple fields together (and a direction for each), required whenever a query filters/orders on more than one field in a way a single-field index can't satisfy. Firestore requires manual creation because it refuses to run any query it can't serve from an existing index, guaranteeing every query is fast and scalable.

• What it is: An ordered index keyed by a combination of fields, e.g. (status ASC, createdAt DESC).

• When you need one: Equality on one field plus a range/order on another, or filters across multiple fields combined.

• Why manual:

  • Firestore's performance model is "query speed scales with result size, not collection size": that only holds if a backing index exists.

  • Composite indexes are combinatorial, so auto-creating every possible one would explode storage and write cost.

• In practice: You declare them in firestore.indexes.json, or the error message gives a console link that builds the exact index for the query.

Firestore indexes every query: it never scans documents, so each query maps to an index. Single-field indexes are created automatically for each field, while composite indexes (covering multiple fields together) must be defined explicitly.

• Single-field indexes:

  • Auto-created for every field, in ascending and descending order, plus array-contains for arrays.

  • Serve simple queries: one equality or one range/order on a single field.

  • You can disable them per-field with exemptions (useful for large strings/arrays you never query).

• Composite indexes:

  • Cover multiple fields in one ordered structure, defined manually.

  • Needed when a query combines filters/ordering across more than one field.

• Why this design:

  • Because all queries are index-backed, latency depends on the number of results returned, not the total documents in the collection.

  • Tradeoff: every indexed field adds write latency and storage cost.

Firestore queries are deliberately constrained so they always resolve against a single index scan: that rules out cheap arbitrary cross-field logic. Historically you couldn't do OR or != at all; modern Firestore added limited support, but it works by fanning out into multiple index lookups behind the scenes, which caps how far it scales.

• The core constraint: A query reads a contiguous range from one index; a true OR across different fields needs disjoint ranges, which a single scan can't express.

• Range filters: Range/inequality filters (<, >, !=) were limited to a single field, because each range needs to be the index's ordered axis (now relaxed somewhat, but still index-bound).

• OR and not-equal today: Supported via or(), in, array-contains-any, and !=, but these run as multiple internal queries merged together, with disjunction limits (e.g. a cap on clauses).

• No queries it can't index: No full-text search, no "not in this list" scans, no joins: those don't map to a bounded index range.

• Why: The whole model trades query flexibility for predictable, result-size-proportional performance at any scale.

You optimize Firestore conceptually by shaping data and queries so each read touches only the documents you actually need, kept cheap by indexes and small page sizes. The mantra is: model for your read patterns, not for normalized purity.

• Model around queries:

  • Denormalize and duplicate data so a screen's data comes from one query, not many round-trips.

  • Use subcollections to scope reads to relevant documents.

• Read less:

  • Always pair queries with limit() and paginate with cursors instead of fetching whole collections.

  • Filter and order on the server so the client never downloads then discards.

• Manage indexes: Create composite indexes for needed queries; exempt fields you never filter on to cut write cost.

• Precompute instead of scanning: Maintain counters/rollups (or use aggregation queries) rather than reading many docs to derive a number.

• Avoid hotspots: Don't use monotonically increasing keys/indexed fields that funnel writes to one index range (the ~500 writes/sec hot-shard limit).

• Cost is reads: Firestore bills per document read, so fewer/narrower reads optimize both latency and cost together.

You paginate in Firestore with query cursors: limit() sets the page size and cursor methods like startAfter() anchor the next page to the last document you saw. This is cursor-based (not offset-based) paging, so each page is fetched efficiently from the index regardless of how deep you go.

• limit(): Caps results per page; you must order the query so "next" is well-defined.

• Cursor methods: startAfter() / startAt() begin the next page after/at a value or document snapshot; endBefore() / endAt() bound the other end.

• Pass the last snapshot: Use the last DocumentSnapshot of the page as the cursor: it handles tie-breaking across the ordered fields automatically.

• Why not offset: Firestore has no efficient offset: skipping N rows still reads (and bills) those N docs, so cursors are both faster and cheaper.

Aggregation queries (count(), sum(), average()) compute a single value over a query's results on the server without returning the matched documents. They were introduced so you can get totals cheaply, instead of reading every document client-side just to count or add them up.

• What they are: Run on a query/collection group and return one computed number, e.g. getCountFromServer(query).

• Why introduced:

  • Before, counting 10,000 docs meant reading 10,000 docs: slow and 10,000 billed reads.

  • They avoid manually maintaining counter documents for many common cases.

• Cost model: Billed in small batches of index entries scanned, far cheaper than reading each document.

• Limits: Computed live (not cached), must resolve from an index, no offline support, and a per-query timeout: for very high-frequency real-time totals, precomputed counters still win.

Firebase Auth manages sessions with two tokens: a short-lived ID token (a JWT) that proves identity for one hour, and a long-lived refresh token that silently mints new ID tokens so the user stays logged in without re-entering credentials.

• On sign-in the SDK receives both tokens: The ID token is a signed JWT containing uid, provider info, and custom claims; the refresh token is an opaque long-lived credential.

• ID token lifecycle:

  • Valid for 1 hour, then expires.

  • The client SDK automatically refreshes it in the background using the refresh token (roughly 5 minutes before expiry or on demand).

• Refresh token lifecycle:

  • Persists across app restarts (stored locally), so the session survives until the user signs out or it is revoked.

  • Revoked on password change, account disable/delete, or explicit revokeRefreshTokens().

• Persistence is configurable: On web, local, session, or none controls where/how long the session is kept.

• Server-side verification: Backends verify the ID token (not the refresh token) with the Admin SDK on each request to authorize the user.

The ID token is a short-lived, verifiable proof of who the user is, sent with each request; the refresh token is a long-lived credential whose only job is to obtain new ID tokens when they expire.

• ID token:

  • A signed JWT (uid, claims, expiry) that any backend can verify offline using Google's public keys.

  • Expires after 1 hour, by design, to limit damage if leaked.

  • Used for authorization: passed to your server or to Firestore/Storage rules.

• Refresh token:

  • An opaque, long-lived token (no readable claims) exchanged at Google's token endpoint for fresh ID tokens.

  • Never sent to your application backend or used for request authorization.

  • Stored securely on the client and revocable server-side.

• Rule of thumb: ID token = identity for this hour; refresh token = the right to keep getting ID tokens.

With Email/Password you own and must protect the credential lifecycle (storage, strength, resets, brute force); with OAuth providers you delegate credential security and identity verification to Google/Facebook, reducing your attack surface but adding a third-party dependency.

• Email/Password:

  • You rely on user-chosen passwords (reuse, weak passwords, phishing risk).

  • Firebase hashes/stores passwords (scrypt), but you must enable email verification and handle password resets safely.

  • Needs protections against enumeration and brute force (Firebase throttles, but consider App Check and rate limits).

• OAuth (Google/Facebook):

  • No password is stored by you; the provider handles credentials and often MFA.

  • Email is typically pre-verified by the provider, raising trust.

  • Risk shifts to provider account compromise and OAuth misconfiguration (redirect URIs, scopes).

• Shared concerns:

  • Account linking: the same email across providers can collide; configure linking behavior carefully.

  • Both ultimately yield the same ID token, so authorization logic is identical downstream.

Anonymous authentication creates a temporary account with a real uid but no credentials, letting a user use the app and accumulate data before signing up; you preserve that data by linking the anonymous account to a permanent credential rather than creating a new account.

• What it is:

  • Call signInAnonymously() to get a persistent uid usable in Security Rules.

  • Useful for try-before-signup flows and carts.

• Upgrading / linking:

  • Create a credential (email/password or OAuth) and call linkWithCredential() on the current anonymous user.

  • The uid stays the same, so all existing data remains owned by that user.

• Edge cases:

  • If the credential already belongs to another account, linking fails (credential-already-in-use); you must merge data manually then sign in to the existing account.

  • Anonymous accounts are cleaned up if abandoned; don't store critical-only data there.

Firebase Hosting is a CDN-backed static host: it serves files (HTML, CSS, JS, images) directly from edge caches. It has no server runtime of its own, so 'dynamic' content is produced by routing matching requests through rewrites to Cloud Functions or Cloud Run.

• Static assets:

  • Uploaded at deploy time and pushed to a global CDN, served fast with configurable cache headers.

  • Each deploy is versioned and atomic, enabling instant rollbacks.

• Dynamic content:

  • Hosting itself runs no code; you map URL patterns to a backend via rewrites in firebase.json.

  • Responses from functions can be CDN-cached if they set Cache-Control, giving dynamic content edge caching too.

• Resolution order: A static file matching the path wins; otherwise rewrites are evaluated, so dynamic backends act as a fallback.

You add a rewrites rule in firebase.json that maps a URL pattern to a Cloud Function or Cloud Run service. Hosting receives the request at the edge and proxies matching paths to that backend, so the dynamic response is served under your Hosting domain.

• Configure the rewrite: Point a glob path to a function name or a Cloud Run serviceId and region.

• Request flow: Static files take priority; unmatched paths fall through to the rewrite and Hosting proxies them to the backend.

• Caching benefit: If the backend sets Cache-Control, the rendered response is cached at the CDN edge, so repeat requests skip the function (useful for SSR).

• Common use cases: Server-side rendering, APIs, and dynamic OG/meta tags served on the same custom domain.

Subcollections nest documents under a parent, modeling ownership and keeping related data scoped; root-level collections are flat and easier to query across all items. The key tradeoff is that Firestore queries are not deep by default, so the choice affects how you can query and aggregate.

• Subcollections:

  • Great for data that belongs to one parent (e.g. users/{id}/orders); keeps documents small and scopes security rules naturally.

  • A normal query only reads one subcollection at a time; querying across all parents needs a collectionGroup query (and its own indexes).

• Root-level collections:

  • Simple to query and filter across every document in one place; good when items are queried independently of any owner.

  • You must store relationship fields (like ownerId) yourself and rely on them for filtering.

• Shared considerations:

  • Both scale similarly: Firestore charges and performs per document read, not per collection size.

  • Decide by access pattern: if you mostly read data scoped to a parent, use subcollections; if you frequently query across all items, prefer root-level (or use collection groups).

Denormalization means duplicating data across documents (e.g. copying an author's name into each post) instead of storing it once and joining. Firestore has no joins and bills per document read, so duplication lets a single read return everything a view needs, trading storage and write complexity for fast, cheap reads.

• Why it's recommended:

  • No server-side joins: you can't merge collections in one query, so embedding needed fields avoids extra lookups.

  • Cost and speed: reads are billed per document, so fewer reads per screen means lower cost and latency.

• The cost of duplication:

  • Updates must fan out to every copy, often via batched writes or a Cloud Function trigger.

  • Risk of temporary inconsistency between copies until the fan-out completes.

• Practical guidance:

  • Duplicate fields that are read often and change rarely (display name, avatar URL).

  • Model around your queries first, then decide what to embed versus reference.

Firestore caps a document at 1 MiB (1,048,576 bytes) including field names and values, and limits index entries and write rates, so you model data to keep documents small and bounded rather than letting them grow without limit.

• Key limits:

  • Document size: 1 MiB max, counting field name lengths plus value sizes.

  • Field/nesting: up to 20 levels of nested map/array depth; a field name path can be long but counts toward the doc size.

  • Write throughput: a single document can be updated at most ~1 write/second sustained (the hotspot rule).

• Influence on modeling:

  • Avoid unbounded arrays/maps inside one doc (e.g. all comments): move growing collections into subcollections.

  • Prefer many small documents over few large ones so reads fetch only what's needed and writes don't collide.

  • Store large blobs (images, files) in Cloud Storage and keep only a URL in Firestore.

  • Denormalize carefully: duplicating data speeds reads but each copy still counts toward its document's limit.

FCM is a messaging pipeline: your app gets a registration token, your server (or the console) sends a message addressed to that token (or a topic) through FCM's backend, and FCM routes it to the device via the platform transport, where the SDK delivers it.

• Registration:

  • The client SDK requests a unique registration token identifying that app instance on that device.

  • Your server stores the token to target the device later.

• Addressing options: Single token, topic (publish/subscribe), device groups, or condition expressions.

• Delivery path:

  • You call the FCM HTTP v1 API; FCM hands off to platform transport (Android transport layer, APNs on iOS, web push).

  • Messages can be queued/collapsed if the device is offline, with TTL and priority controls.

• Handling: The SDK either auto-displays a notification or passes data to your handler depending on payload type and app state.

FCM (push notifications) reaches users when they are outside the app, while In-App Messaging shows contextual messages only while the user is actively using the app. They serve different moments: re-engagement versus in-session guidance.

• Firebase Cloud Messaging:

  • Delivers push notifications to the device even when the app is closed or backgrounded.

  • Best for re-engagement, alerts, and time-sensitive updates that pull users back in.

  • Requires notification permission; deliverability depends on OS/transport.

• In-App Messaging:

  • Shows banners, modals, or cards only when the user is already in the app.

  • Triggered by events and targeted with Analytics audiences; no permission needed.

  • Best for onboarding, promotions, surveys, and feature discovery during a session.

• Choosing: Need to reach absent users: FCM. Need to guide present users contextually: In-App Messaging. They are complementary, often used together.

Because Remote Config values are fetched from the server at runtime, you can ship the code paths once behind flags and then control which users get which behavior from the console, with no app store release. A/B testing splits users across variants; a kill switch flips a flag to disable a broken feature instantly.

• A/B testing:

  • Remote Config integrates with Firebase A/B Testing: define variants of a parameter and a target metric.

  • Users are randomly bucketed; each variant reads a different value, and Firebase measures impact on the goal.

  • Roll out the winning value to 100% from the console once results are clear.

• Kill switch:

  • Wrap a risky feature in a boolean flag (e.g. new_checkout_enabled) that defaults safely.

  • If it misbehaves in production, set the flag to false; clients disable it on their next fetch/activate.

• Caveats:

  • The code for both paths must already be in the build; flags only choose between shipped paths.

  • Changes are not instant: they apply on the next fetch (mind the minimum fetch interval and activation).

A fatal error is an uncaught crash that terminates the app, while a non-fatal is an error you caught and chose to report without the app dying. Crashlytics records both but treats them differently, which matters because fatals reflect hard stability while non-fatals surface handled-but-undesirable conditions.

• Fatal error (crash):

  • An unhandled exception/signal that crashes the process; captured automatically and reported on next launch.

  • Drives the headline crash-free users metric and is prioritized as highest severity.

• Non-fatal error:

  • You log it explicitly (e.g. recordException()) from a catch block; the app keeps running.

  • Reported with a full stack trace but counted separately from crashes.

• Why it matters:

  • Lets you triage: fatals are urgent stability issues, non-fatals reveal degraded paths (failed network calls, recoverable bugs) that hurt UX without crashing.

  • You can monitor handled errors in production that would otherwise be invisible, while keeping your true crash rate accurate.

Firebase Performance Monitoring is a tool that collects timing and network data from real user devices to help you understand your app's runtime behavior in production. It works primarily through traces: named records that measure how long a specific block of activity takes.

• A trace measures duration between two points: It records the time elapsed plus optional custom metrics (counters) and attributes (string dimensions for filtering).

• Two kinds of traces:

  • Automatic traces: app start, foreground/background sessions, screen rendering, and HTTP/S network requests captured by the SDK without code.

  • Custom traces: you instrument a code path manually with trace.start() and trace.stop() to time a specific operation.

• Network request monitoring: Reports response times, payload sizes, and success rates per endpoint, helping isolate slow APIs.

• Aggregated, real-world data: Metrics are sampled and aggregated across devices, OS versions, and countries, so you see actual user-experienced performance, not just lab tests.

Firebase Analytics (Google Analytics for Firebase) logs user and event data, and you use that behavioral evidence to prioritize engineering work, validate features, and decide where to invest performance and infrastructure effort.

• Prioritize what to build or fix: Funnel and event data show where users drop off, telling you which flows deserve refactoring or simplification.

• Validate features with A/B testing: Combined with Remote Config, you ship a variant to a cohort and measure conversion before committing to a full rollout.

• Guide technical scaling decisions: Usage patterns (peak times, popular screens, device/OS mix) inform caching, query optimization, and which platforms to support.

• Custom events for domain signals: Log events like logEvent('checkout_started') to track behavior unique to your app rather than relying only on automatic events.

• Caveat: analytics is sampled and delayed: Use it for directional trends, not real-time precise counts; pair with logging/BigQuery export when exactness matters.

Deleting a user from Firebase Auth only removes their authentication identity (the UID and login credentials); it does NOT touch any documents they created in Firestore. That orphaned data remains until you explicitly delete it, so you must build cleanup yourself.

• Auth and Firestore are decoupled: Auth manages identity; Firestore is a separate database with no automatic cascade delete when a UID disappears.

• The standard solution: a triggered Cloud Function:

  • Use the auth.user().onDelete() trigger to run cleanup automatically when an account is removed.

  • In it, delete the user's document(s) and any subcollections keyed by their UID.

• Beware nested data: Deleting a document does not delete its subcollections; you must recurse or use the firebase firestore:delete recursive helper.

• Compliance and bulk deletes: For GDPR-style requests, Google's official Delete User Data extension automates removing a UID's data across Firestore, RTDB, and Storage.

You secure Firebase Storage with Security Rules that match the file path against the authenticated user's UID, so each user can only read and write files under their own folder. No custom backend is needed because the rules are enforced server-side by Firebase itself.

• Structure paths by UID: Store files under a predictable prefix like users/{userId}/... so the path itself encodes ownership.

• Match path against the token: In rules, compare the path segment to request.auth.uid; access is allowed only when they match.

• Enforced server-side: Rules run on Google's infrastructure on every request, so a malicious client cannot bypass them.

• Add validation in the same rule: Use request.resource.size and request.resource.contentType to restrict file size and type on upload.

In Firebase Auth there is no built-in 'soft delete' feature: a hard delete permanently removes the account and UID, while a 'soft delete' is a pattern you implement yourself by disabling the account and/or flagging the user as deleted in your database while keeping their records. The choice mainly affects whether Firestore data stays linked to a recoverable identity.

• Hard delete:

  • Calls deleteUser() and permanently removes the credential and UID; the user cannot log back in.

  • Firestore documents keyed by that UID become orphaned, so you must cascade-delete (e.g. via an onDelete() Cloud Function).

• Soft delete (a self-built pattern):

  • Disable the account with updateUser(uid, { disabled: true }) and set a flag like isDeleted: true on the Firestore profile.

  • The UID and data are preserved, so the account is recoverable and historical relationships stay intact.

• Implications for Firestore data:

  • Hard delete demands an explicit cleanup or anonymization strategy to avoid orphaned/PII data.

  • Soft delete requires Security Rules and queries to filter out deleted users so they don't appear active.

• Compliance angle: GDPR 'right to be forgotten' usually requires a true hard delete plus removal of associated data, not just disabling.

A BaaS like Firebase trades control and flexibility for development speed and reduced operational burden: you get auth, database, storage, and hosting out of the box, but you give up fine-grained control over the backend and accept the platform's constraints and pricing model.

• Advantages of BaaS:

  • Speed: ship features fast without writing servers, auth, or scaling logic.

  • Managed scaling and ops: Google handles infrastructure, uptime, and replication.

  • Built-in realtime, auth, and SDKs reduce boilerplate dramatically.

• Costs of BaaS:

  • Less control: you can't tune the database engine or run arbitrary server logic outside Cloud Functions.

  • Vendor lock-in: data models and APIs are proprietary, making migration hard.

  • Cost at scale: per-operation billing can become expensive for read-heavy or high-volume workloads.

  • Query limitations: NoSQL constraints (no joins, limited aggregation) can force awkward data modeling.

• Custom backend tradeoff: Full control and portability, but you own scaling, security, and maintenance, and time-to-market is slower.

• Rule of thumb: Favor BaaS for MVPs, startups, and standard CRUD/realtime apps; favor custom for complex queries, strict cost control at scale, or heavy regulatory/control requirements.

Both apply multiple writes atomically (all-or-nothing), but a transaction can read documents first and base its writes on those values with conflict detection, while a batched write is a blind set of writes with no reads. Use a transaction when writes depend on current data; use a batch when you already know the values.

• Transaction:

  • Reads then writes, atomically; retries on concurrent modification (optimistic concurrency).

  • Use when a write depends on the current state, e.g. transferring a balance or conditional updates.

  • Can be retried multiple times, so its callback must be idempotent.

• Batched write:

  • A group of set/update/delete operations committed atomically, with no reads and no conflict checks.

  • Use to write/update many documents you already have values for, e.g. fan-out writing the same record to several places.

  • Lower overhead and never retries; just succeeds or fails as a whole.

• Shared limits: Both are capped (up to 500 operations) and are atomic across documents and collections.

• Rule of thumb: Need current data to decide what to write -> transaction; already know the data -> batch.

They are special sentinel values that tell Firestore's server to compute the final value at write time, instead of trusting a value the client sends. FieldValue operations let you do atomic, server-side mutations (set the server clock, add/remove array elements, increment counters) safely under concurrency.

• Server timestamps:

  • Written with FieldValue.serverTimestamp(): the server stamps the time, so it doesn't depend on the device clock (which can be wrong or manipulated).

  • Guarantees consistent ordering across clients in different time zones or with skewed clocks.

• Atomic counters:

  • FieldValue.increment(n) adds/subtracts on the server, so two clients incrementing at once won't overwrite each other.

  • Avoids the read-modify-write race you'd get reading a value then writing value+1.

• Array operations: FieldValue.arrayUnion(...) adds elements only if not already present; FieldValue.arrayRemove(...) deletes matching ones, all atomically.

• FieldValue.delete(): Removes a single field from a document during an update.

• Why server-side instead of client values:

  • Correctness under concurrency: increments and array changes are atomic, no lost updates.

  • Trust: clients can't fake the timestamp or clobber a counter; logic runs where you control it.

Firestore bills primarily on operations, not bandwidth or storage: you pay per document read, write, and delete (plus modest storage and egress). Because pricing scales with document operations, your data model and query shape directly drive cost.

• The billed dimensions:

  • Reads: one charge per document returned by a get or query (and per document change delivered to a listener).

  • Writes: one charge per document created or updated.

  • Deletes: one charge per document removed.

  • Plus stored data (GiB/month) and network egress.

• Why per-document matters:

  • A query returning 1,000 documents is 1,000 reads, regardless of how small they are.

  • Counting documents by reading them all is expensive; use aggregation queries (count()) or a stored counter instead.

  • A query that matches no documents still bills a minimum of one read.

• Design implications:

  • Denormalize so a screen needs few document reads, not many joins.

  • Use limit and pagination to cap reads per query.

  • Maintain counters with increment() rather than reading whole collections to tally.

Strong consistency means a read always reflects the latest committed write; eventual consistency means replicas converge over time so a read may briefly return stale data. In Firebase, Firestore reads are strongly consistent, while some replicated/cached paths are eventually consistent.

• Strong consistency:

  • Firestore document reads and queries return the most recent committed data, and transactions are atomic.

  • Important when correctness depends on the latest value (balances, inventory).

• Eventual consistency:

  • Replicas/caches may lag briefly before converging.

  • Shows up with offline persistence and local cache: a client sees its own write immediately (latency compensation) before the server confirms.

• Practical note: Listeners may first fire with cached/local data, then update once the server value arrives; check metadata like fromCache or hasPendingWrites.

Firestore supports atomic transactions and batched writes, but its NoSQL model trades away joins, complex multi-row relational integrity, and ad-hoc queries, so transactional data must be modeled carefully and often denormalized.

• What you gain:

  • ACID transactions across documents via runTransaction(), and atomic batched writes.

  • Automatic scaling and real-time sync without managing servers.

• What you trade off:

  • No joins: related data must be denormalized, risking duplication and update anomalies.

  • Limited transaction scope and contention: transactions retry on conflict, and high-contention documents bottleneck.

  • Aggregations (sums, counts) are awkward: often need counters or aggregation queries rather than native SQL.

  • Billing is per read/write, so denormalized fan-out writes can get costly.

• Rule of thumb: Good for document-centric transactional data; for heavy relational integrity and complex reporting, a relational DB is a better fit.

Choose Firebase when you want a fully managed, tightly integrated suite (auth, realtime DB, functions, hosting, analytics) for fast mobile/web development; lean toward Amplify for deep AWS integration or Supabase when you need an open-source, relational (Postgres/SQL) backend.

• Pick Firebase when:

  • You want the fastest path with mature SDKs, real-time sync, and integrated services out of the box.

  • Mobile-first apps benefit from its analytics, crash reporting, and messaging.

• Pick AWS Amplify when:

  • You're already on AWS and want to compose services (Lambda, AppSync/GraphQL, DynamoDB, Cognito).

  • You need fine-grained AWS control and broader cloud ecosystem reach.

• Pick Supabase when:

  • You want a relational SQL database (Postgres) with joins and complex queries.

  • You value open-source and the ability to self-host to avoid lock-in.

• Key deciding factors: Data model (NoSQL document vs. relational SQL), ecosystem you live in, and tolerance for vendor lock-in.

Firebase Data Connect is a managed backend service that connects Firebase apps to a PostgreSQL database (Cloud SQL), letting you use SQL/relational data while keeping Firebase's GraphQL-style schema, type-safe SDKs, and security model.

• The gap it fills: Firestore is NoSQL: relational joins, strong relations, and complex queries are awkward. Data Connect brings a true relational store into the Firebase ecosystem.

• How it bridges:

  • You define a schema and queries/mutations in GraphQL; it provisions tables in Cloud SQL for PostgreSQL.

  • It generates type-safe client SDKs, so apps call named operations instead of writing raw SQL or exposing the DB.

• Security: Operations are authorized server-side with auth-based rules (e.g. tied to request.auth), so clients never get a direct DB connection.

• When to choose it: Relational data with rich joins and constraints, while still wanting Firebase Auth integration and generated SDKs.

Treat PII as something to minimize, isolate, lock down with strict Security Rules, and ideally process server-side: never trust the client to protect it, and only store what you truly need.

• Minimize and separate: Collect only what's necessary; store PII in a separate, tightly-scoped collection (e.g. users/{uid}/private) apart from public profile data.

• Lock down access: Security Rules so only the owner (request.auth.uid == uid) or privileged roles can read it; default-deny everything else.

• Process sensitive logic server-side: Use Cloud Functions with the Admin SDK for operations needing extra data the client shouldn't see; consider field-level encryption for highly sensitive values.

• Defense in depth: Enable App Check to block unauthorized clients, and audit access.

• Compliance and lifecycle: Honor GDPR/CCPA: support deletion/export, set retention, and review Google's data-processing and residency terms.