Resilient comp authorization: staying live when connectivity drops

A casino floor does not stop for a network outage. If comp authorization stops with it, hosting halts or the rules get bypassed — and the second outcome is the one that costs you.

Comp authorization is not a back-office report you can rerun in the morning. It sits in the moment a host offers value to a patron, on a floor that runs around the clock. That places a hard requirement on the software: it has to be always-on, and it has to stay useful even when the things around it fail. This guide sets out how AEGIS, the comp authority engine, is built to stay up — and to keep operating when connectivity drops.

The stakes: a floor that never stops

An integrated resort operates continuously. Patrons play at 3am; hosts make offers on a graveyard shift with no head-office desk to call. An authorization system that goes down leaves the floor with two bad options. It can halt hosting — no comp moves until the system returns, which frustrates high-value patrons and pushes staff to improvise. Or staff bypass the rules and issue value outside any governed process, which is the worse outcome: value leaves the building with no authority check and no record. The whole point of authorization is to remove that choice. So the system cannot simply be highly available on paper; it has to keep the floor operating without ever abandoning governance.

Resilient by design

AEGIS is built so that no single failure takes authorization down. The services are containerised and stateless, deployed active-active across data centres. Statelessness matters here: because a service instance holds no session of its own, any instance can answer any request, and losing one changes nothing a patron would notice. Active-active means the second data centre is not a cold spare waiting to be woken — it is already serving traffic. There is no single point of failure to nurse, and the stack recovers on its own rather than waiting for an operator to notice and intervene. Resilience is a property of the architecture, not a runbook someone has to remember at 3am.

A sanctioned offline path

Some failures reach past the data centre. A cut link, a floor-network fault, a wider outage — connectivity can drop between the floor and the service. AEGIS is designed for that case rather than surprised by it. A defined offline path keeps the floor operating under the last-known authority: the delegation-of-authority matrix as it stood before the drop. Hosts keep making governed offers; the system keeps checking them against the authority it last held. When the connection returns, the offline decisions reconcile automatically — replayed, sealed, and folded back into the record. Nothing is lost, and nothing was ever ungoverned.

Why "sanctioned" is the whole point

The word doing the work is sanctioned. Every floor already has an unofficial offline mode: paper chits, a phone call to a manager, a note to sort it out later. That is exactly the ungoverned bypass authorization exists to eliminate, and an outage is precisely when it appears. A sanctioned offline path is different because it is part of the design. Decisions made offline stay inside policy — checked against the last-known matrix — and stay inside the audit trail, sealed the moment they happen so reconciliation is a replay, not a reconstruction. An ad-hoc workaround abandons governance at the worst possible moment. A sanctioned path carries governance through the outage and out the other side.

Real-time, even under load

Staying up is not enough if the system is slow when it matters. AEGIS keeps the fast path fast by splitting the work into two deliberately separate engines. A decision engine answers authority checks in milliseconds — under roughly five — so a host never waits on a comp. A workflow engine runs the slower, longer-lived work: escalations up the reporting line, reminders, holds. Because the two are separate, an escalation that takes minutes to reach the right manager never blocks a decision that should take milliseconds. Every decision is broadcast the moment it happens on an Apache Kafka event backbone, and sealed to an immutable audit trail — hash-chained and anchored into immudb, which the platform itself cannot alter. Speed and proof are not a trade-off here; they run on different engines.

Put together, that is what always-on has to mean for comp authorization. Not a promise on a status page, but an architecture that expects failure — a single node lost, a data centre lost, connectivity lost — and keeps the floor both operating and governed through all three.

Frequently asked questions

What happens to comp authorization if the network drops?

The floor keeps operating. AEGIS has a sanctioned offline path: if connectivity drops, the floor continues under the last-known authority matrix rather than halting or bypassing the rules. When the connection returns, offline decisions reconcile automatically, so nothing is lost and nothing is ungoverned.

Why does a "sanctioned" offline mode matter?

Because an offline path that is part of the design keeps decisions inside policy and inside the audit trail. An ad-hoc workaround — paper chits, a manager's phone call, a spreadsheet — abandons governance at exactly the moment it matters. A sanctioned path operates under the last-known authority and seals every decision for reconciliation.

How does AEGIS avoid a single point of failure?

AEGIS runs as containerised, stateless services deployed active-active across data centres. There is no single node whose loss stops authorization, and the stack recovers on its own rather than waiting for someone to intervene.

Does resilience slow the real-time decision down?

No. AEGIS splits the work into two deliberately separate engines: a decision engine that answers authority checks in milliseconds, and a workflow engine that runs escalations, reminders, and holds. Because they are separate, a long-running escalation never blocks the fast path.