An iGaming platform event integration built for replay

The scenario

A fictional iGaming product team needs to connect an external platform to its back-office reporting. Provider callbacks have different names, timestamps, and retry behaviour from the internal product events. This example would use sandbox data to build an integration boundary; it would not attempt to implement a wallet or settlement ledger.

Keep provider details inside an adapter

The adapter would verify the callback using the provider’s documented authentication or signature scheme. It would validate required identifiers and payload sizes before recording an event. If signatures depend on raw request bytes, parsing and reserialising the body before verification would break the check.

A normalized internal event would carry provider, provider event ID, entity reference, event type, and timestamps. Original payloads would be stored only where needed, with restricted access and a defined retention period. Downstream reporting would depend on the normalized contract rather than importing every provider-specific field.

Make the inbox the durable source of processing state

An inbox table would use a uniqueness constraint on provider and event identity. PostgreSQL conflict handling could acknowledge a repeated delivery without creating another row. Processing would then move through explicit states such as received, validated, applied, or quarantined.

Redis could help coordinate short-lived worker activity, but an expiring cache entry would not be the only protection against duplicate processing. Event application would rely on durable state. If a downstream API supports idempotency keys, the adapter would reuse the stored event identity when retrying.

Plan for ordering and controlled replay

A later state could arrive before an earlier callback. The adapter would use provider sequence information where available and otherwise apply a documented transition policy. Contradictory events would be quarantined for review rather than resolved using arrival time alone.

A replay tool would operate on selected stored events, record the adapter version, and show what it intends to reprocess. Sandbox fixtures would cover duplicates, malformed messages, missing dependencies, and interrupted workers. Reporting counts would be reconciled against the provider’s sandbox exports before a production scope is considered.

What to validate

• The same signed callback can be delivered twice safely.
• Invalid authentication never reaches event application.
• An out-of-order event follows the documented policy.
• Replay is scoped, recorded, and repeatable.

The tradeoff

Provider contracts differ. This pattern would need adaptation to the actual callback and retry specifications. Financial balances require a separate ledger design and cannot safely be inferred from a reporting event stream.