Production Checklist

Work through this before you ship. Every item here is a failure that is cheap to prevent now and painful to diagnose later.

Submitting tickets

• Ticket IDs are UUIDs generated in your backend, and a timed-out CreateTicket is retried with the same ID.
• Everything the engine needs is in engine_input; everything you want back is in metadata.
• Player.latencies uses host keys that map directly onto your provisioning layer’s placement identifiers.
• Your mmr values are on the same scale as the queue’s mmr_normalization_ref. The parameter defaults assume a normalised 0.0-1.0 range; a raw ladder rating in the thousands will dominate every other term until you rescale.
• The player is shown a queue state on the CreateTicket ack, not a match.

Consuming outcomes

• Outcomes are handled idempotently, keyed on Outcome.id or Match.id. Delivery is at-least-once on every sink.
• Your handler acknowledges fast and does provisioning asynchronously. A handler that provisions before responding will hit the delivery timeout and cause a retry storm, with duplicate provisioning attempts as the visible symptom.
• ticket.expired and ticket.removed are handled as lists; both are batched.
• ticket.removed reasons are distinguished: re-queue for most, stop routing for QUEUE_RETIRED.

Honouring matches

• match.created is treated as a commitment: you either provision, or you compensate with ReactivateTickets.
• You walk host.acceptable before declaring provisioning failed.
• terminal_retention_ttl_secs is set above your orchestrator’s worst-case provisioning time plus the fallback walk.
• A non-empty failed_ticket_ids from ReactivateTickets is alerted on, not ignored.

Error handling

• FAILED_PRECONDITION on CancelTicket is handled as “a match is coming”, and the match.created that follows is still honoured.
• UNAVAILABLE is retried with backoff rather than surfaced to the player.
• FAILED_PRECONDITION with x-ivk-reason: QUEUE_RETIRING stops you routing to that queue instead of retrying it.

Configuration

• expiration_ttl_secs is slightly above the longest wait your game will display, so the timeout the player sees is your decision.
• Credentials are loaded from your secret store, not from source control, configuration files, or a game client.
• If you run more than one ruleset, fairness_weight reflects which mode is the headline one.

Backfill

• Backfill requests are cancelled when a match fills or ends.
• Nothing in your launch plan depends on backfill being fulfilled. It is not yet implemented.