ADR 0003: Use Firestore as the Job Queue
- Status: Superseded in part
- Date: 2025-10-15
- Updated: 2026-07-23
- Deciders: Akshay
- Tags: data-model, infrastructure
Contextβ
Clients need real-time state for video jobs. The original choice was to use
jobs/{jobId} both as the visible state machine and as the effective queue,
avoiding a separate broker at low volume.
Original decisionβ
Firestore job documents were the queue and the client-visible state. Storage
triggers advanced pending β running β done | failed, while clients subscribed
to snapshots.
Current decisionβ
Firestore remains the authoritative state, ownership, retry, quota-release, and UI-subscription record. Dispatch is no longer Firestore-only:
- The Storage trigger validates the upload and advances the job.
- It enqueues the
dispatchGpuJobFirebase Task Queue worker. - The task has three attempts, 10β120 second backoff, and five concurrent dispatches.
- Terminal handlers use Firestore transactions so only one path wins.
This change supersedes the βno separate queue serviceβ portion of the ADR, not the decision to keep durable client-visible job state in Firestore.
Consequencesβ
Positiveβ
- Clients still receive real-time updates without polling.
- Dispatch retries and concurrency limits no longer need ad hoc logic.
- Job state remains easy to inspect and operate in Firestore/Admin.
claimJobDoneandfailJobmake slot release idempotent.
Negativeβ
- State and dispatch now span Firestore and Firebase Task Queue.
- Operators must inspect both function/task logs and the job document.
- A permanently failed dispatch still needs terminal failure/reconciliation.
Follow-up actionsβ
- Add atomic terminal transitions.
- Add hourly
reconcileStuckJobs. - Add
adminRetryJob. - Move dispatch to
dispatchGpuJobTask Queue. - Re-evaluate throughput and dead-letter needs as volume grows.
Referencesβ
acesense-auth-function/video/gpu/enqueue.tsacesense-auth-function/video/gpu/dispatch-worker.tsacesense-auth-function/video/reconcile.ts- Job document
Was this page helpful?