small app, about 1,200 users, no change in traffic or signups. reads went from roughly 2m a month to about 80m over nine days, starting the day after a release. the usage dashboard cheerfully confirms that the reads happened but not which collection or which screen caused them. how do you attribute this without bisecting the whole release?
turn on the billing export to bigquery if you haven't — it gives you cost by sku and day, so you can at least confirm the jump is document reads rather than egress or storage, and pin the exact day. cloud monitoring will give you read counts by database and operation type, but it will not tell you which collection or which screen, which is the thing you actually want. so instrument it yourself: wrap your query helper so every read logs a screen name and a collection, ship that behind a flag, and give it a day. in my case the wrapper found it in about four hours and the answer was a screen nobody had thought about.
before assuming it's a listener leak, check the boring explanation: a query somewhere lost its limit, or a list that used to be small isn't small any more. firestore bills per document returned, so a dashboard that reads an entire collection to compute a count is fine at 200 documents and ruinous at 20,000, and the growth curve looks exactly like a bug. the structural fix is to stop reading collections to derive numbers — keep a counter document or an aggregation and update it on write. paying per document read means list views and analytics screens are where the money goes, every time.
the counter document approach saved us roughly an order of magnitude on a dashboard that showed six totals. six queries reading everything, replaced by one document read.
worth checking things that aren't your users at all. mine was a dev script polling a collection every second, left running on a spare laptop under a desk for two weeks while i was on holiday. no code change, no traffic change, just a machine quietly asking the same question 86,400 times a day. check for service account traffic before you tear the release apart.
listener leak, missing limit, or a robot you forgot about. instrument reads per screen before bisecting — an afternoon of logging beats three days of guessing.
@edge_runtime_bo · 3mo ago · 2 replies
start with real-time listeners, because that's where nearly all of these come from. a listener attached inside a component that remounts will re-subscribe every time, and each new subscription pulls the initial snapshot again, so a list of 200 documents on a screen that remounts on every keystroke turns into an astonishing number very quickly. grep for every onSnapshot in the diff, check each one has an unsubscribe that actually runs on unmount, and check none of them are created inside a render path. mine was a listener in a component that remounted whenever a parent's state changed, which was constantly.
Reply
Report
@chmod_confused · 3mo ago
add double-invoked effects in development to that list. i spent a day convinced i had a duplicate subscription bug in production when half of what i was seeing locally was the framework deliberately mounting twice, and the real leak was elsewhere.
Reply
Report