Why the free bet system breaks under growing load
A free bet is not a number on the balance, but an entity with a lifecycle: issued, reserved for a bet, wagered, expired. While the free bet system handles hundreds of bets per day, transitions between states can be made with a single record and reconciled manually. At a flow of thousands of simultaneous bets, this approach stops holding state.
The first failure is parallel bets on one bonus. Two operations simultaneously read the state “free bet active” and both write it off: the result is a double bonus accrual, and discrepancies in bonus accruals surface in reports.
Reconciliation of the player account with the bonus journal stops matching, and then every discrepancy has to be investigated bet by bet.
The second failure is stuck bonuses. Canceling a bet, recalculating an event, or rolling back by a risk department decision returns the bet, but does not return the bonus to its original state: the cancellation operation bypasses the bonus journal.
The player sees a balance that support cannot explain, while the free bet itself remains in an intermediate state and blocks issuance of the next one.
The third is the growth of manual bonus edits. Each edit erases the trace of the operation, audit becomes non-reproducible, and the load on the bonus loop grows nonlinearly: edits breed new discrepancies, and discrepancies breed new edits.
Next we examine how this is addressed architecturally: idempotent keys, a unified operations journal, and rebuilding state from events.
What a managed bonus loop delivers: effects and metrics
A managed bonus loop starts with the fact that every accrual is an event with an idempotent key and a record in an immutable journal.
Only then is bonus accrual time measured from condition triggering to funds appearing on the balance, rather than “on average per day.” We capture the same metric on cancellation: how long it takes from decision to compensating entry.
Working benchmarks after migration to such a loop: the share of automatic accruals is 95–98%, and the remainder are disputed cases that still require a human.
Manual operations drop to dozens of actions per week instead of hundreds: the employee handles exceptions rather than manually granting free spins. Canceling an erroneous bonus takes minutes, not hours.
Whole classes of errors disappear completely: double accrual when a payment system event is redelivered, a bonus for a canceled deposit, a discrepancy between the blockchain balance and internal accounting, an expired free spin for which the obligation is not closed. All this is caught by a rule, not by reconciliation at the end of the month.
Accounting for bonus liabilities becomes continuous: at any moment you can see how many wagering conditions are open, what volume of winnings is reserved, how many free spins can still be activated. For audit and finance, this is a snapshot for the current second instead of an on-demand export.
We assemble these snapshots from the same events: an indexing layer on The Graph provides aggregates, and the dashboard shows the dynamics of accruals and cancellations.
Anomalies — a spike of identical bonuses from one address or a drop in the share of automatic decisions — are visible immediately, not after complaint review.
Free bet and free spin accrual modes: comparison of schemes
Free bet and free spin accrual modes differ not in the size of the gift, but in how the system calculates liabilities to the player.
A one-time promotion produces a sharp spike of events in a short window, while a permanent program creates a steady background that must be accounted for in every balance calculation.
The choice of mode affects both the accounting load and which restrictions of bonus schemes will have to be introduced immediately.
Restrictions are designed in advance: an accrual limit per player and per period, wagering conditions, bonus lifetime, cancellation rules upon bet return.
The free spin accrual scheme is usually tied to a specific game and bet denomination — this changes both accounting and the volume of reconciliations with the game provider.
| Mode | When it fits | Restrictions |
|---|---|---|
| One-time bonus promotions | Launch, event, acquisition of new players | Peak accounting load, manual setup for each promotion, risk of double accrual when an event repeats |
| Permanent bonus program | Established base, regular activity | Liabilities accumulate: accounting for unwagered bonuses and regular reconciliation are needed |
| Accumulative mechanics: streaks, levels | Retention, long sessions | Progress must be stored and restored after a failure, accrual rollback is more complex |
| Free spins by activity event | Reactivation, tied to one game | Hard coupling to game and bet, more reconciliations with the provider |
In practice, modes are combined: a permanent program maintains the background, one-time promotions create spikes for a specific date.
This works reliably only with a unified accrual journal, where each event is marked with source and mode — otherwise scheme restrictions cannot be consolidated and it cannot be proven that a bonus was issued once.
Stages of designing a casino bonus loop
The bonus loop changes the player's balance: the free bet system, free spins, cashback, and deposit offers live in one accounting model. If it is assembled on the fly, the first conflict of conditions produces a double accrual or a stuck status. Therefore, we fix the stages of designing the bonus system before the first configuration.
- Bonus rules audit — we analyze triggers, limits, wagering requirements, lifetimes, and priority between promotions. The output is a rules registry and a list of contradictions.
- Bonus accounting scheme — we separate real and bonus funds, describe statuses, the operations journal, and idempotency keys so that a repeated request does not double the accrual.
- Issuance logic design — we tie bonuses to events (deposit, bet, losing streak) and determine where wagering is calculated and where progress is only recorded.
- Configuration and integration — we set rules, connect the loop to game providers, payments, and the player account, and distribute operator rights.
- Bonus accrual testing — we run scenarios: parallel requests, bet cancellation, deposit return, negative balance, expiration, manual adjustment.
- Fault tolerance — we test peak issuances and behavior when the provider is unavailable; the journal and state snapshots allow recalculating the balance and rolling back an error.
- Bonus system handover — documentation, bonus handling regulations, accesses, and training: the client's team launches new promotions itself.
Free bet and free spin system: what we hand over to the client
We hand over not “code that works on our staging environment,” but a package that is deployed in your environment and verified step by step.
The free bet system is assembled from independent parts: rules change without modifying the core, the journal is exported in full, access is granted by roles. Below is exactly what your team receives.
- Bonus rules configuration: reward types, per-player limits, activity windows, promotion priority when deadlines overlap. A new rule is introduced by editing configuration, not by a new release.
- Accrual flow scheme: the path from trigger — deposit, series of bets, promo period — to crediting free spins and free bets, with protection points against double accrual and failure handling at each step.
- Bonus access policies: operator, analyst, and auditor roles, a rights matrix for issuance, cancellation, and manual adjustment, restrictions by player segments and jurisdictions.
- Bonus operations journal: immutable records with initiator, reason, rule version, and link to the original transaction — any balance discrepancy is investigated using it.
- Operations regulations: accrual rollback procedure, incident response times, escalation points, and responsible parties on the client side.
- Bonus system documentation: description of entities and fields, instructions for adding a new reward type, and a checklist of checks before launching a promotion.
Acceptance takes place in a clean environment: we deploy, run control scenarios, and reconcile the journal with the expected result. If it matches, the package is yours and is maintained by your team without our involvement.
Case study: how the bonus loop stopped losing accruals
Where accruals were lost
Bonus system case study: for an operator with free bets and free spins, rewards came from four sources — promotional mechanics, partner campaigns, cashback, and manual manager edits.
Each source wrote to its own table, and the final balance was assembled by nightly reconciliation, which did not match if an event arrived again.
The root cause was not in accrual formulas, but in the absence of a single write point.
Two parallel requests for one free spin produced a double credit, a canceled promotion left a “hanging” balance, and discrepancies reached 6–8% of daily volume — roughly the same number of disputes went to support.
What we changed and what we achieved
We migrated the bonus loop to an event journal: accrual, write-off, and expiration are separate records with a unique operation key.
The journal was placed in PostgreSQL with a unique index on this key, so a repeated event from the source does not create a second record, and the balance is calculated from the journal rather than stored in a separate field that gets overwritten during simultaneous requests.
Rollback was addressed by the same solution: the journal is immutable, and recalculation of any period reproduces the same picture as at the moment of accrual.
Old balances were migrated with checksums for each player — discrepancies were zeroed out before enabling the new rules, not after.
Discrepancies before and after: the share of disputed accruals fell from 6–8% to fractions of a percent.
Bonus reconciliation time decreased from a nightly procedure lasting several hours to a report built in minutes, and bonus-related support requests fell 4–5 times — the player sees the reason for each accrual in history, and the manager resolves a dispute by the operation key without pulling exports.
How a free bet differs from a free spin in liability accounting
A free bet is a bet at the operator's expense: the player places a bet without debiting their own funds, and the liability depends on the outcome of the event and the odds, so only the upper payout limit is known in advance.
A free spin is a fixed number of spins on a slot with a known spin value: the liability cost is determined immediately upon issuance.
Hence the difference in the recognition moment. A free spin enters the liability register at the moment of accrual — the number and price of the spin are already known.
A free bet remains contingent until the bet is settled: recognizing it in advance means overstating the balance by all unwagered coupons. At this junction, data in the free bet system and in financial accounting diverge — the accrual is either duplicated or lost.
Bonus limits are calculated in different units: free spins — by number of spins per player, slot, and period; free bets — by bet denomination and number of coupons, since their value changes together with the odds.
To bring both to a single program budget, both values are converted to expected value and only then compared with the overall limit.
Reconciliation is also different. For free spins, control points are issuance, actual use, and the remaining unused spins; a discrepancy means a lost event or a double record.
For free bets, they reconcile the amounts of settled bets, odds, and the share of unsettled coupons that hang as a contingent liability. If both types lie in one table without a sign of the nature of the liability, the discrepancy cannot be localized, and limits drift.
Therefore, in the data model these are two different types of liability: each has its own recognition moment, its own limit counters, and its own reconciliation procedure. Then the bonus program report matches, and unsettled free bets do not distort the balance.
Technical concerns about bonus architecture
Before finalizing the architecture, clients test it for resilience to three scenarios: double accrual, cancellation of an already issued bonus, and changing promotion rules on the fly.
Below are direct answers to common engineering questions about bonus architecture: how these cases are handled in the free bet system without manual edits and without stopping the promo.
What happens if a bonus is accrued twice?
Every accrual is tied to an event key — a bet attempt, payment, or condition achievement. A repeated arrival of the same event does not create a second record: the system checks the key against the operations journal and returns the already existing result. Restarting queue processing and scheduled adjustments are safe — the balance is not doubled.
Can a bonus be canceled after accrual?
Cancellation is not deletion, but a compensating record in the immutable journal: you can see who initiated it, for what reason, and what happened to the player's balance.
If free spins have been partially played or a free bet has been wagered, the remainder is calculated from a state snapshot at the moment of cancellation, not by recalculating the entire history anew.
How can promotion rules be changed without breaking already issued bonuses?
Rules are versioned: a promotion has a set of conditions with an effective date. A bonus issued under the previous version is played out according to it — changing conditions does not rewrite history and does not create disputed situations with players. The new version applies only to subsequent accruals.
Let's discuss the task: where the bonus loop begins
The first conversation with engineers is not a presentation, but the removal of uncertainty. To discuss the bonus system and a design request substantively, we need inputs for estimation: accrual rules, accounting model, integration points, and load profile. The more specific the source data, the fewer assumptions in the bonus work plan.
- Accrual rules: bonus types — free spins, sports free bets, cashback — wagering conditions, lifetime, behavior upon bet cancellation or player inactivity.
- Accounting model: how bonus and real balances are separated, in what order funds are debited, how the bet contribution to wagering is calculated.
- Randomness sources and reporting: who issues free spins and how the spin result is recorded — an internal generator or the game provider side.
- Integration points: payment loop, game providers, antifraud, and CRM — which events are exchanged, in real time or via exports.
- Restrictions: jurisdictions, per-player limits, history storage requirements, who has the right to change a rule and how this is recorded.
- Load profile: size of the active base, peak frequency of bets and spins, allowable bonus issuance delay.
- Current environment: what already works, what bottlenecks are known, what cannot be broken during migration.
From these inputs we assemble a bonus work plan: accounting and wallet scheme, accrual service, event processing, reporting, and a migration procedure with rollback to the previous environment. Describe the task — we will come back with an estimate and a breakdown of stages.