Listener Fan-Out at Scale, Query Selectivity, Reconnects, Resume Behavior, and Bandwidth / Read Cost

Learning outcomes

1. AtlasMart problem: 100,000 dashboards make one product update expensive

A single Firestore document update is cheap to imagine from the writer's viewpoint. Realtime cost is driven by the read side too. If many active listeners include that document in their result set, the same logical update can fan out to many clients. Firestore scales the infrastructure, but your application still owns query selectivity, result size, client count, reconnection pattern, and bandwidth.

listener_surface ≈ active_clients × matching_result_set + matching_changes_delivered_over_timeFor Standard:  initial sync -> document reads (+ applicable index-entry reads)  add/update -> document read per affected result document  removed because data changed -> document read  document deleted -> no listener read charge for that deletion eventFor Enterprise:  initial query sync -> read units  subsequent realtime changes -> realtime-update units (size-sensitive)Always use current regional pricing and actual usage telemetry for money.

2. Broad versus scoped query experiment

Use two listeners against the same six-item fixture. The broad listener tracks the four lowest-stock products globally. The scoped listener tracks up to four low-stock products for seller-a. Run the deterministic Admin pulse that modifies two seller-a and two seller-b documents. Instrument snapshot count, docChanges() count, approximate JSON payload bytes, and active listener count.

<!doctype html><meta charset="utf-8"><pre id="out"></pre><script type="module">import { initializeApp } from "https://www.gstatic.com/firebasejs/12.19.0/firebase-app.js";import { getAuth, connectAuthEmulator, signInAnonymously } from "https://www.gstatic.com/firebasejs/12.19.0/firebase-auth.js";import {  getFirestore, connectFirestoreEmulator, collection, doc, query, where, orderBy, limit,  onSnapshot, setDoc, updateDoc, serverTimestamp, disableNetwork, enableNetwork} from "https://www.gstatic.com/firebasejs/12.19.0/firebase-firestore.js";const app = initializeApp({ projectId:"demo-atlasmart-firestore", apiKey:"demo-key", appId:"demo-app" });const db = getFirestore(app); connectFirestoreEmulator(db, "127.0.0.1", 8080);const auth = getAuth(app); connectAuthEmulator(auth, "http://127.0.0.1:9099", { disableWarnings:true });const credential = await signInAnonymously(auth);const uid = credential.user.uid;console.log("uid", uid);const out=document.querySelector('#out');const stats={active:0,snapshots:0,changes:0,payloadBytes:0};const enc=new TextEncoder();function watch(name,q){  stats.active++;  const stop=onSnapshot(q, {includeMetadataChanges:true}, snap=>{    const rows=snap.docs.map(d=>({id:d.id,...d.data()}));    const changes=snap.docChanges().map(c=>`${c.type}:${c.doc.id}`);    stats.snapshots++; stats.changes+=changes.length;    stats.payloadBytes+=enc.encode(JSON.stringify(rows)).byteLength;    out.textContent += JSON.stringify({name,meta:snap.metadata,changes,stats:{...stats}})+"\n";  });  return ()=>{stop();stats.active--;};}const broad=query(collection(db,'catalogItems'),orderBy('stock','asc'),limit(4));const scoped=query(collection(db,'catalogItems'),where('sellerId','==','seller-a'),orderBy('stock','asc'),limit(4));const stopBroad=watch('broad',broad), stopScoped=watch('seller-a',scoped);window.cleanup=()=>{stopBroad();stopScoped();};</script>

The byte counter is an application-side approximation of JSON you chose to serialize—not Firestore's network-billing byte count. The change counter is not a billing counter either. Its purpose is comparative: which query causes the screen to receive irrelevant changes under the same mutation workload?

3. Reconnects and resume behavior

SDK listeners can reconnect automatically after transient connectivity loss. Treat this as state synchronization, not exactly-once event replay. The service/SDK may use internal resume mechanisms, but your application contract remains “eventually regain a current query snapshot or surface an error.” Do not persist callback sequence numbers as if they were durable event offsets.

For Standard mobile/web billing, current documentation distinguishes persistence state: with offline persistence enabled, a disconnect longer than 30 minutes is charged like a new query; with offline persistence disabled, a disconnect/reconnect is charged like a new query each time. Query index-entry charging rules can also apply. Rules that use dependent document reads can incur extra reads when the query is issued, updated, reconnects, Rules change, or dependent documents change.

4. Bound the result set before tuning listeners

Use realtime for the part of the screen that truly needs realtime. A long order-history list can load with cursor pagination while only the current order status has a document listener. “Everything live” is rarely a requirement.

5. Standard vs Enterprise vs Pipeline vs MongoDB compatibility

• Standard Native/Core: realtime listeners are built in; indexes are required for queries.
• Enterprise Native/Core: realtime listeners and offline persistence are available, but optional indexing and Enterprise billing change performance/cost reasoning.
• Enterprise Native/Pipeline: Pipeline operations do not support realtime listeners; use Core operations when realtime/offline behavior is required.
• MongoDB compatibility: change streams are a distinct API/operational model and are currently Preview; do not teach onSnapshot metadata as MongoDB change-stream semantics.

Lab checklist

1. Run the six-item seed and open fanout.html.
2. Record the initial rows for broad and seller-a queries.
3. Run node admin-pulse.mjs; compare which mutations changed each result set.
4. Call window.cleanup() and verify active returns to zero.
5. Reload, disable/enable network, and observe that callback/reconnect count is not a durable-event count.
6. Document a production measurement plan: active listeners, result-set sizes, delivered bytes, reconnect rate, Standard read/index-entry metrics or Enterprise units, and p95/p99 update-to-render latency.

Production judgment

Listener scalability is usually a product/query-shape problem before it is an SDK problem. Keep live result sets selective, detach them when hidden, separate durable events from synchronized UI state, and budget reconnects. For extreme broadcast fan-out, consider whether a purpose-built messaging/event channel plus occasional state reads fits better.

Knowledge check

1. Why is docChanges().length not a billable-read counter?
2. What happens to Standard billing after a reconnect when offline persistence is disabled?
3. Why can a scoped listener reduce noise?
4. Can listener callbacks be treated as exactly-once event delivery?
5. Why separate Standard and Enterprise cost models?

Summary and next step

You now have a measurable listener surface. Lesson 4 makes ownership explicit in framework/component lifecycle so the application cannot accidentally keep old screens subscribed forever.

Authoritative references

• Get realtime updates with Cloud Firestore — document/query listeners, initial snapshots, docChanges(), detach/error behavior.
• Access data offline — cache behavior, fromCache, metadata-change events, network transitions.
• JavaScript SnapshotMetadata — hasPendingWrites and fromCache semantics.
• JavaScript SnapshotListenOptions — metadata updates and listen-source options.
• Understand Cloud Firestore billing — Standard listener reads, reconnect charging, index-entry reads, Rules-dependent reads, and bandwidth.
• Firestore Enterprise pricing — initial read units and separate realtime-update units.
• Enterprise Core realtime listeners — Core listener support and Pipeline listener boundary.
• Enterprise Native Core/Pipeline overview — Core realtime/offline support versus Pipeline query operations.
• MongoDB-compatibility change streams — separate Preview change-stream model; do not equate it with Web SDK onSnapshot.
• Firebase release notes — current CLI/SDK versions used by this lab.