Design that survives production
Software architecture for iGaming platforms
Most iGaming platforms are not limited by code quality. They are limited by decisions made early about where the wallet sits, how bonuses touch it, what a game round is allowed to assume, and whether a second brand means a second deployment. Argon designs those boundaries with people who have already lived with the consequences of getting them wrong.
01
Where teams get stuck
- Adding a brand means forking the platform
- Multi-tenancy that was never designed gets simulated with environment variables and copied databases, and every launch costs what the first one did.
- The bonus engine and the wallet are tangled
- When promotional logic writes directly to balances, every campaign becomes a financial risk and no one can reconstruct why a player has the balance they have.
- Nobody can explain the system end to end
- Twelve services, no diagram anyone trusts, and integration behaviour that only three people understand. Onboarding is slow and incidents last longer than they should.
iGaming consideration
Casino, sportsbook, bingo and lottery sharing one balance changes bonus design, reconciliation, reporting and every supplier contract. It is a decision to make deliberately, early.
02
What we do
- Domain decomposition and service boundaries
- Where wallet, player, game, bonus, payment, compliance and reporting begin and end, which data each owns, and what is allowed to call what.
- Wallet and ledger design
- Append-only ledgers, balance derivation, cash and bonus separation, idempotent write paths, reconciliation jobs and a provable audit trail.
- Event streaming and integration contracts
- Kafka topic design, event schemas and versioning, delivery guarantees, replay strategy, and the API contracts between your platform and every supplier.
- Multi-brand and multi-jurisdiction design
- One platform, many brands, several licences and different rules per market, without a code fork per launch. Tenant isolation, per-brand configuration and jurisdiction-aware behaviour.
- Consistency and failure design
- Idempotency keys, transactional boundaries, compensating actions, retry semantics and what the system does when a provider times out mid-payment.
- Performance and capacity modelling
- Concurrency targets, hot paths, query budgets, caching strategy and the non-functional requirements that a load test can actually be written against.
- Modernisation and migration
- Getting from where you are to where the design says you should be, in shippable steps, with the business running throughout. Strangler patterns, dual writes, backfills and cutover plans.
- Architecture governance
- Decision records, review gates, reference implementations and the light process that keeps a growing team from re-litigating settled questions.
03
What you receive
- Target architecture with component, data-flow and sequence diagrams
- Architecture decision records covering every significant choice and the option we rejected
- Service boundary and ownership map, including which service owns which data
- Data model and event schema catalogue with versioning rules
- Non-functional requirement budget: latency, throughput, availability, recovery targets
- Sequenced migration roadmap, sized, with a first increment that can start on Monday
04
How the work runs
01
Current state
Read the code, the infrastructure and the incident history. Interview the people who carry the pager. Produce the diagram nobody currently has.
02
Constraints and targets
Commercial roadmap, licence plans, volume expectations, team shape and budget. Architecture without constraints is decoration.
03
Options and trade-offs
Two or three viable designs, each with cost, risk and what it forecloses. We recommend one and say why the others lose.
04
Design
The chosen architecture in detail, down to the contracts and the data ownership, with decision records as we go.
05
Roadmap
Sequenced increments, each independently valuable and shippable, sized in engineering weeks.
06
Embed and review
We stay close during the first increments, review the pull requests, and adjust the design against what production teaches.
05
Why iGaming differs
- A single wallet across products is an architectural commitment
- Casino, sportsbook, bingo and lottery sharing one balance changes bonus design, reconciliation, reporting and every supplier contract. It is a decision to make deliberately, early.
- Game rounds must reconcile, always
- Provider callbacks arrive late, twice, or not at all. The architecture has to make an unreconciled round detectable and repairable without a manual ledger edit.
- Regulators audit the design, not just the data
- Jurisdictions increasingly ask how player funds, self-exclusion and reporting are enforced structurally. An architecture that answers that is cheaper than a certification retrofit.
06
Tools and methods
- Services
- Node.js · TypeScript · Express · Go · Java
- Data
- MongoDB · PostgreSQL · Aurora · Redis · ClickHouse
- Messaging
- Kafka · MSK · SQS · EventBridge
- Practice
- C4 model · ADRs · domain-driven design · contract testing
- Typical team
- Principal architect plus domain specialists
07
Questions
Do we have to rewrite?
Usually no, and we will argue against it unless the evidence demands it. Most platforms need three or four boundaries corrected and a migration path, not a green field. A rewrite is the most expensive way to fix a design problem and the easiest to under-estimate.
Microservices or a monolith?
Whichever matches your team size and change pattern. A well-modularised monolith beats eleven services owned by five engineers. We have seen both failure modes and we size the answer to your organisation, not to fashion.
Will you implement the design or only document it?
Either. Many clients take the design and build it themselves, which is why the deliverables are written to be executed by someone else. When you want us to deliver it, the same architect stays on the engagement.
Can you work alongside our existing architect?
Yes, and that is often the most productive shape: your architect owns the outcome, we bring the pattern library from platforms that have already been through this, and we take the adversarial review role that is hard to play from inside.
Related
- Engagements
- Under NDA as standard
- People
- Background-checked engineers
- Data
- GDPR and DPA ready
- Infrastructure
- World-renowned cloud providers
Next step
Tell us what you are building, or what you are about to buy.
One working day to a reply, from an engineer rather than an account manager. Under NDA as standard, before anything is shared.