Real-time support for multiple currencies and rates
Introduction
Online casinos operate in markets with different currencies: EUR, USD, GBP, RUB and many local ones. In order for players to bet and receive winnings in their own currency, the platform must dynamically convert amounts at current rates, ensuring transparency, accuracy and minimal delays.
1. Multicurrency architecture
1. Currency Service
A separate microservice responsible for receiving, storing and distributing courses.
Exposes API '/rates? base = USD & symbols = EUR, GBP, RUB 'and WebSocket change stream.
2. Exchange Rate Provider
External APIs (Fixer. io, Open Exchange Rates, bank gateways) with a guarantee of data freshness (update once a minute).
Flexible configuration of the priority of providers and fallback when the main one is unavailable.
3. Caching and TTL
Redis cache with key = 'rates: USD' and TTL = 60 s for REST; Pub/Sub channel for WebSocket updates without unnecessary requests.
4. CDN for statics
Access to courses via edge calls (if regionale setting is not critical operational value).
2. Data storage and model
'exchange _ rates' table
```sql
CREATE TABLE exchange_rates (
base_currency CHAR(3) NOT NULL,
target_currency CHAR(3) NOT NULL,
rate DECIMAL(18,8) NOT NULL,
fetched_at TIMESTAMP NOT NULL,
PRIMARY KEY (base_currency, target_currency)
);
```
Historical courses
For analytics and rolling back erroneous updates, the 'exchange _ rates _ history' table with the identical + 'updated _ at' schema.
Precision and scale
8 decimal places allow you to convert any amounts up to cents with a margin of error <0. 0001.
3. Conversion of bets and payments
1. Conversion calculation
On receipt of bid:
2. Fees and spread
Defined at tenant/brand level, added as a multiplier ('effectiveRate = rate (1 + spread)').
Clear fixing of spread in the conversion request and in the transaction log.
3. Atomicity of operations
All calculations and write-offs take place in the database transaction in order to eliminate the out-of-sync between the conversion and the accounting record.
4. Volatility handling and risks
Lock-in course
At the start of the session or at the first conversion of the bet, the course is "fixed" for the entire game session of the player in order to exclude arbitration for quick fluctuations.
Stored in 'player _ sessions'.
Stale rate detection
If'fetched _ at'is older than the threshold (e.g. 5 min), conversion is prohibited until the course is updated.
Alerting
Alerts when the number of successful updates falls below the SLA level (for example, <95% per hour) and when the permissible volatility is exceeded (> 1% per 1 minute).
5. Integration with game engines and microservices
gRPC/REST
Game Engine requests converted amounts through the '/convert? from=EUR&to=USD&amount=10. 00`.
Mandatory metadata transfer: 'session _ id', 'player _ id' for logging.
Event-driven
When updating courses, the Currency Service publishes the 'RateUpdated (base, target, rate)' event to Kafka; Consumers (Analytics, Reporting) update their aggregates.
6. Fault tolerance and scaling
Replica-set Redis
Sentinel or Cluster Mode for fault tolerant cache.
Stateless Currency Service
Horizontal scaling via Kubernetes HPA by response latency and QPS.
Circuit Breaker
Protection against freezing when external APIs are unavailable: fallback to the last successful course or refusal to convert.
7. Safety and compliance
TLS/SSL for all external and internal calls.
Audit log
Records all conversion requests with rate, timestamp, and source IDs.
Regulatory requirements
Local laws may require publication of courses or limitation of the spread; these parameters are configured per region.
8. Monitoring and metrics
Prometheus
Метрики: `currency_rate_fetch_success_total`, `currency_rate_fetch_error_total`, `conversion_requests_total`, `conversion_latency_seconds`.
Grafana-dashboard
Course lifetime, update rate, p95 latency conversions, number of failures due to stale rates.
Conclusion
Real-time multi-currency support requires a dedicated Currency Service with fault-tolerant cache, accurate rate storage and logging, atomic rate and payout conversions, volatility protection, and regulatory compliance. With this architecture, the platform provides players with transparent and correct operations in their native currency without downtime and errors.
Online casinos operate in markets with different currencies: EUR, USD, GBP, RUB and many local ones. In order for players to bet and receive winnings in their own currency, the platform must dynamically convert amounts at current rates, ensuring transparency, accuracy and minimal delays.
1. Multicurrency architecture
1. Currency Service
A separate microservice responsible for receiving, storing and distributing courses.
Exposes API '/rates? base = USD & symbols = EUR, GBP, RUB 'and WebSocket change stream.
2. Exchange Rate Provider
External APIs (Fixer. io, Open Exchange Rates, bank gateways) with a guarantee of data freshness (update once a minute).
Flexible configuration of the priority of providers and fallback when the main one is unavailable.
3. Caching and TTL
Redis cache with key = 'rates: USD' and TTL = 60 s for REST; Pub/Sub channel for WebSocket updates without unnecessary requests.
4. CDN for statics
Access to courses via edge calls (if regionale setting is not critical operational value).
2. Data storage and model
'exchange _ rates' table
```sql
CREATE TABLE exchange_rates (
base_currency CHAR(3) NOT NULL,
target_currency CHAR(3) NOT NULL,
rate DECIMAL(18,8) NOT NULL,
fetched_at TIMESTAMP NOT NULL,
PRIMARY KEY (base_currency, target_currency)
);
```
Historical courses
For analytics and rolling back erroneous updates, the 'exchange _ rates _ history' table with the identical + 'updated _ at' schema.
Precision and scale
8 decimal places allow you to convert any amounts up to cents with a margin of error <0. 0001.
3. Conversion of bets and payments
1. Conversion calculation
On receipt of bid:
- ```pseudo
- rate = getRate(playerCurrency, platformCurrency)
- platformAmount = round(playerAmount rate, 2, ROUND_HALF_EVEN)
- ```
- Similarly, when paying: calculation in the opposite direction, taking into account the commission.
2. Fees and spread
Defined at tenant/brand level, added as a multiplier ('effectiveRate = rate (1 + spread)').
Clear fixing of spread in the conversion request and in the transaction log.
3. Atomicity of operations
All calculations and write-offs take place in the database transaction in order to eliminate the out-of-sync between the conversion and the accounting record.
4. Volatility handling and risks
Lock-in course
At the start of the session or at the first conversion of the bet, the course is "fixed" for the entire game session of the player in order to exclude arbitration for quick fluctuations.
Stored in 'player _ sessions'.
Stale rate detection
If'fetched _ at'is older than the threshold (e.g. 5 min), conversion is prohibited until the course is updated.
Alerting
Alerts when the number of successful updates falls below the SLA level (for example, <95% per hour) and when the permissible volatility is exceeded (> 1% per 1 minute).
5. Integration with game engines and microservices
gRPC/REST
Game Engine requests converted amounts through the '/convert? from=EUR&to=USD&amount=10. 00`.
Mandatory metadata transfer: 'session _ id', 'player _ id' for logging.
Event-driven
When updating courses, the Currency Service publishes the 'RateUpdated (base, target, rate)' event to Kafka; Consumers (Analytics, Reporting) update their aggregates.
6. Fault tolerance and scaling
Replica-set Redis
Sentinel or Cluster Mode for fault tolerant cache.
Stateless Currency Service
Horizontal scaling via Kubernetes HPA by response latency and QPS.
Circuit Breaker
Protection against freezing when external APIs are unavailable: fallback to the last successful course or refusal to convert.
7. Safety and compliance
TLS/SSL for all external and internal calls.
Audit log
Records all conversion requests with rate, timestamp, and source IDs.
Regulatory requirements
Local laws may require publication of courses or limitation of the spread; these parameters are configured per region.
8. Monitoring and metrics
Prometheus
Метрики: `currency_rate_fetch_success_total`, `currency_rate_fetch_error_total`, `conversion_requests_total`, `conversion_latency_seconds`.
Grafana-dashboard
Course lifetime, update rate, p95 latency conversions, number of failures due to stale rates.
Conclusion
Real-time multi-currency support requires a dedicated Currency Service with fault-tolerant cache, accurate rate storage and logging, atomic rate and payout conversions, volatility protection, and regulatory compliance. With this architecture, the platform provides players with transparent and correct operations in their native currency without downtime and errors.
