Skip to content

Backup Queues

Taxi & Private HireProductsDispatch › Backup Queues

Generally available

When a feeder queue's drivers can't cover a trip, its BackupQueueGroups widen the trip's eligibility pool over time — each group adds its queues to the eligible set once `releaseTimeSeconds` elapses. Pure eligibility expansion: dispatch does not differentiate drivers by which group their queue belongs to. Operators use this to express cross-fleet handoff ("Fleet A first; if no driver after 60s, also offer to Fleet B").

Example request

POST /client/{clientId}/backupqueuegroup

{
  "feederQueue": {
    "id": "<id>"
  },
  "priority": 0,
  "releaseTimeSeconds": 0,
  "queues": [
    {
      "id": "<id>"
    }
  ]
}

Example shape, derived from the BackupQueueGroup fields — indicative, not the authoritative schema (that arrives with the API reference).

Endpoints

MethodPath
POST /client/{clientId}/backupqueuegroup/{backupQueueGroupId}/queue/{queueId}
POST /client/{clientId}/backupqueuegroup · primary
DELETE /client/{clientId}/backupqueuegroup/{backupQueueGroupId}
GET /client/{clientId}/backupqueuegroup/{backupQueueGroupId}
DELETE /client/{clientId}/backupqueuegroup/{backupQueueGroupId}/queue/{queueId}
POST /client/{clientId}/backupqueuegroup/{backupQueueGroupId}

Full request/response schemas and an interactive explorer will live in the API reference (coming soon).

Use cases

Operator flows that exercise this feature.

Configure a backup queue

config risk: medium

Create a backup-queue group and add fallback queues for when the primary queue empties.

  1. POST /client/{clientId}/backupqueuegroup
  2. POST /client/{clientId}/backupqueuegroup/{backupQueueGroupId}/queue/{queueId}

Fields

FieldTypeDescription
feederQueue Queue Feeder queue that delegates eligibility expansion to this backup group. Different feeder queues have independent backup configurations.
priority smallint Ordering within the feeder queue — lower runs first. Display-only today (dispatch treats all activated backup queues as one eligibility pool); reserved so operators can stack groups in a sensible order in the UI.
releaseTimeSeconds integer Seconds since the trip was first dispatched, after which this group's queues join the trip's eligibility pool. Lets operators configure per-group handoff delays (Fleet A only for 60s, then Fleet B added at 120s, etc.).
queues Collection Pool of queues that become eligible for this trip once releaseTimeSeconds elapses. Each backup queue still applies its own fleet gating + decision tree.
clientId bigint Tenant scope. Every tenant-aware entity carries this; `ClientFilter` enforces row-level isolation on read; the multi-tenancy routing layer (`/client/{clientId}`) sets it at create time. Surfaced only under `admin` / `tripLog` groups — never to end users.
internalKey string Optional client-supplied external reference / idempotency key. When present, lets external systems correlate platform-side records back to their own source-of-truth ids. Not persisted to a column — populated by the request handler when the caller sets it.
__objectType string Discriminator string (entity class short-name) emitted alongside the id in serialized output. Resolved at read time by `getObjectType()`; lets the FE dispatch entity-specific rendering without inspecting the URL.
id bigint Snowflake-style primary key (unsigned BIGINT). Generated by `IdFactory` at create time; surfaced to the FE / API as a `G`-prefixed string and stripped back to plain bigint server-side before Doctrine lookup.
createdDate integer Unix timestamp the row was first persisted. Set in the entity's PrePersist hook; never rewritten on subsequent updates.
updatedDate integer Unix timestamp the row was last touched. Bumped on every commit that hits the Doctrine UoW for this entity; drives FE invalidation + the listing change cursor.
passiveUpdatedDate int Read-through alias for `updatedDate` exposed under different serializer groups. Lets the FE distinguish "real edit" from "background touch" projections without changing the underlying column.
listingUpdatedDate int Listing-projection timestamp surfaced only under the `listMode` group. Driven by `TripCache` and other listing-shape refreshers separately from `updatedDate` so a listing rebuild doesn't trigger detail-page invalidation.