In this chapter
We'll fix last chapter's own stale-read problem for real — a real subscription that pushes every change to a client automatically — and meet realtime listeners and event-driven updates as the actual mechanism behind "the database tells you."
The Problem in Real Life
Sarah tries the obvious fix first: have the support app re-check the order every few seconds, just in case. It works, sort of — but it means asking hundreds of times for one real change, most of those checks finding nothing new at all.
Mike asks why the app has to keep asking in the first place.
Why is our app the one doing the asking? Shouldn't the database just tell us?
Mike
Asking Repeatedly vs. Being Told
A subscription is standing interest
Registered once, a subscription tells the database to keep this specific client informed from now on.
A realtime listener is what receives it
The client-side mechanism that actually gets each real, pushed update as it happens.
Event-driven, not timer-driven
A subscribed client updates in response to a real write happening — not on a schedule hoping something changed.
The database does the telling
Verified: subscribing once means both of clientA's later writes reach clientB automatically, with zero .get() calls.
Realtime Listeners & Subscriptions
A subscription is exactly Mike's question, answered: instead of a client repeatedly asking "has this changed yet?", it registers real, standing interest in a specific piece of data — a realtime listener — and the database itself takes on the job of telling that client the moment something actually changes. This is event-driven updates: the client's view updates in response to a real event (a write happening), not on a timer guessing when to check.
One real line — clientB.subscribe(...) — changes everything. clientA's two writes now each trigger a genuine, real-time notification to clientB, automatically. clientB never calls .get() even once here — it doesn't have to. The database itself is doing the telling.
clientB.subscribe("orders/4471/status")clientA.set("orders/4471/status", "Out for Delivery")clientA.set("orders/4471/status", "Delivered")
This is the exact same order path as last chapter's stale-read demo. The only difference is the subscription — run this and watch clientB actually receive both updates live, no polling, no guessing.
This is the real mechanism behind "the database tells you." A subscription isn't a clever trick layered on top of a normal database — it's a genuinely different relationship between client and server: the server holds open a real, standing connection (or its equivalent) and pushes data the instant it changes, instead of waiting to be asked. Firestore's own real listeners, and every comparable BaaS realtime feature, work exactly this way underneath.
This is also precisely what last chapter's core realization meant in practice. The database isn't a passive place data sits until a client remembers to look — with a real subscription in place, it becomes an active participant in how GreenMart's own apps actually communicate updates to each other, in real time, without either side writing polling logic by hand.
Key Takeaway
Sometimes the database isn't just where the backend stores data — it becomes part of how the application communicates with the data. A subscription is that realization made mechanical: register real interest once, and the database pushes every real change from then on — the client never has to ask again.
Why This Matters
Every remaining chapter in this Act builds on a client actually being subscribed and reachable. The next chapter's whole problem — what happens when a client genuinely can't be reached, offline — only makes sense once this chapter's "reachable and current" case is understood as the normal, working state.
GreenMart's support app can now learn about order changes the instant they happen, with zero polling. A subscribed, always-online client is the easy case, though — the next chapter is about what happens when a client genuinely isn't there to be told anything.