Case study — Flashy Gold
A rewards ledger that reconciles, by construction
- Scale
- A live rewards ledger serving production traffic across the group’s consumer network.
- Write path
- Idempotent, versioned contract
- Status
- Live in production
The challenge
A balance ledger fails quietly. A retried request that isn’t idempotent doesn’t crash — it just credits twice, and the discrepancy surfaces weeks later as a reconciliation break nobody can explain from the logs alone.
The approach
The write path is a versioned contract
The credit endpoint is specified as an OpenAPI document, not left as an implementation detail two services happen to agree on.
Idempotency keys derived from the event
A key like duel-win:{duelId} rather than a timestamp — a key that differs on every retry is the absence of one wearing the costume of one, and that exact mistake reached production before the rule was written down.
A named source on every entry
Every credit states what caused it, so a balance can be explained after the fact rather than merely totalled.
The outcome
The ledger has run in production with the credit path published as a stable, versioned contract — the same discipline the wallet service on the platform catalogue is built to.
The platforms this evidences
Considering something similar?
The capability above is licensable independent of this engagement — see the platform page for what is and is not white-labelled.