The launch of a new iGaming project, FinTech application or Web3 service is often accompanied by aggressive marketing campaigns that attract tens of thousands of users in the first hours. A sudden traffic spike is both a success for business and a severe stress test for the IT infrastructure. If the servers go down during a massive influx, the cost of acquiring each customer (CAC) will turn into a direct loss for the company.
At MonoSoftware, we design systems for high fault tolerance and horizontal scaling. In this article, we analyze architectural patterns and solutions that allow you to handle hundreds of thousands of active users without failures or loss of performance.
1. Main bottlenecks during peak loads
When thousands of users log on to a platform simultaneously, the traditional monolithic architecture breaks down at three key points:
- Database I/O: Direct heavy SQL queries to read and write balances, game sessions or transaction history will block threads and exhaust the connection pool.
- Synchronous inter-service communication: If, when processing one user action, a microservice waits for a response from three external APIs (for example, KYC, payment gateway and anti-fraud), the latency increases exponentially.
- Memory leaks and incorrect caching: Lack of optimization on the backend side leads to RAM being clogged with unvalidated sessions, causing container crashes (OOM Kill).
2. Architectural stack for working with Highload
To ensure stability under 100,000+ DAU loads and tens of thousands of RPS (requests per second), we take a multi-layered approach to organizing our infrastructure.
Important: The main rule of the Highload architecture is that no user request should perform heavy calculations synchronously in the main application thread.
A. Read/Write Separation (CQRS and Replication)
To work with databases (PostgreSQL / ClickHouse), thread separation is used:
- Master DB: Accepts only critical write operations (replenishment of balance, rate, transfer) with mandatory atomicity check and pessimistic transaction locking.
- Read replicas: Multiple replicas that distribute the load of reading directories, event lists, and user profiles among themselves.
B. Asynchronous processing via message queues
All heavy and non-critical operations for instant response (sending push notifications, calculating referral bonuses, analytics, logging) are sent to message queues - RabbitMQ or Apache Kafka. The backend returns an instant 202 Accepted response to the user, and background workers sort out tasks as resources become available.
B. Multi-layer caching (In-Memory Data Stores)
Up to 90% of read requests can be served without accessing a relational database. We implement Redis/KeyDB at three levels:
- Session and token cache: Instant authorization.
- Hot Data: Quotes, Betting Odds, Game States, Leaderboards (Sorted Sets in Redis).
- Rate Limiting: Protection against spam and DDOS attacks at the cache level.
3. Infrastructure preparation and autoscaling
Designing the right codebase architecture is only half the battle. The second half is competent server orchestration.
- Kubernetes (K8s) and Horizontal Pod Autoscaler (HPA): Services are packaged in Docker containers. When the CPU/RAM load increases or the number of requests increases, HPA automatically raises new application replicas in seconds.
- Cloudflare & CDN: Static content (graphics, scripts, WebGL resources) is cached on Edge servers around the world, taking up to 70% of traffic from our servers.
- Circuit Breakers: If an external payment gateway or partner API starts to freeze, a circuit breaker temporarily isolates that service, preventing the entire system from cascading down.
4. Summary decision matrix for Highload
| System Component | Standard Approach (MVP) | Highload approach (MonoSoftware) |
|---|---|---|
| Database | Single PostgreSQL/MySQL | Master + Read Replicas + Sharding + ClickHouse for Analytics |
| Event Handling | Synchronous (Rest API) | Asynchronous (Kafka/RabbitMQ) |
| Caching | Missing / Basic in memory | Redis Cluster (In-Memory) + CDN at the Network Edge |
| Scaling | Vertical (purchase of a more powerful VPS) | Horizontal (Kubernetes HPA, Auto-scaling groups) |
| Testing | Manual / Basic Unit Tests | Stress Testing (k6/Locust) with 500,000+ RPS Simulation |
5. Release readiness checklist
Before launching an iGaming or FinTech product into production, we recommend that you conduct a mandatory check:
- Stress Testing: Performed simulation testing via k6 or Locust exceeding target DAU by 3-5 times.
- Monitoring and alerting: Configured metrics in Grafana/Prometheus and alerts in Telegram/Slack for an increase in 5xx errors, database latency and RAM fullness.
- Graceful Degradation: The system behavior scenario under extreme loads has been configured (for example, disabling the display of heavy animation to preserve the functionality of the transaction core).