We promised customers that their usage dashboard would update instantly. Then the first production spike hit and our cron-based aggregation fell behind by hours. Support tickets piled up. We needed real-time metering, not nightly batches.
Here’s the Firebase-first architecture we ended up with. It keeps latency low without forcing us to babysit servers.
Pieces That Make It Work
Cloud Run ingestion
Every usage event hits a stateless Cloud Run service. We validate Firebase Identity tokens, attach project metadata, and push the event onto Pub/Sub. Cold-start latency stays under 200 ms, even under load.
Firestore as the ledger
Events land in Firestore using deterministic document IDs. That gives us real-time listeners for the dashboard and a durable audit trail for finance. We partition by customer and day to keep hot documents from thrashing.
Background processors
Cloud Run jobs pull from Pub/Sub and handle rating, aggregation, and alerting. Each job is idempotent; we rely on Firestore transactions to protect against duplicates. Token validation details live here.
The Event Lifecycle
- Client sends a signed request with usage details.
- Ingestion writes a minimal event document and pushes metadata onto Pub/Sub.
- Workers calculate costs, update running totals, and emit alerts if thresholds hit.
- Firestore listeners trigger UI updates inside the customer dashboard.
From request to updated dashboard: roughly two seconds for most workloads.
Realtime metering flow
Server Calls] --> Ingest[Cloud Run
Ingestion Service] Ingest --> PubSub[(Pub/Sub Topic)] Ingest --> Ledger[Firestore Event Ledger] PubSub --> Workers[Cloud Run
Rating Jobs] Workers --> Totals[(Firestore Usage Totals)] Workers --> Alerts[/Spend Threshold Alerts/] Totals --> Dashboard[Customer Dashboard] Ledger --> Dashboard Alerts --> Support[Support &
Finance Playbooks]
Operational Lessons
- Granularity matters: we group tiny events into five-second windows to avoid write amplification.
- Backfills need throttling: we replay historical usage through the same pipeline but cap concurrency so real-time traffic stays fast.
- Observability first: Cloud Logging traces plus Firestore metrics help us spot hotspots before customers do.
Customers now trust the numbers because they see them change while they’re still in the product. Support trusts them because the event history matches what finance exports at month end.
If you’re still running nightly summaries, start by piping a single feature through this stack. Once you see the difference in support volume, it’s hard to go back.