How to Design a High‑Throughput Lottery System: Load‑Balancing, Redis, and Tomcat Tuning

Problem Scenario

Lottery, red‑packet and flash‑sale systems often experience a traffic spike where millions of users request a draw at the same moment. A typical example is a lottery with 10,000 prizes and several hundred thousand participants, which can generate load that is hundreds or thousands of times higher than normal.

Unoptimized Architecture

The initial design forwards every request from a load‑balancer to a Tomcat‑based lottery service. The service implements the draw logic on MySQL and, when a user wins, calls a separate Tomcat‑based gift service to issue the prize. All traffic, including invalid or duplicate requests, reaches the backend.

Load‑Balancer Rate Limiting

Duplicate‑draw protection : Configure the load balancer (e.g., Nginx) to reject requests from the same user within a short window (commonly 1 minute). The rule is implemented with a shared store such as Redis or ZooKeeper that records the last request timestamp per user.

Early termination after all prizes are drawn : The draw service updates a shared flag (e.g., a Redis key or a ZooKeeper ZNode) when the total number of winning draws reaches the configured limit. The load balancer monitors this flag and, once set, returns a “lottery ended” response for all subsequent requests, effectively dropping >99 % of the traffic.

Tomcat Thread‑Pool Tuning

Each incoming request is handled by a dedicated Tomcat worker thread. Load‑testing shows a practical range of 200–500 threads: fewer threads under‑utilise CPU, while more threads cause CPU saturation and possible crashes. Adjust the maxThreads parameter based on observed CPU load and request latency, and re‑test after each change.

Core Draw Logic Migration to Redis

Even after load‑balancer filtering, a few thousand requests may still reach the lottery service. Scaling Tomcat instances alone does not solve the database bottleneck. Replacing MySQL with Redis for the core draw logic eliminates the relational‑database contention. Typical implementation uses atomic Redis commands (e.g., INCR, DECR) or a Lua script to decrement the remaining prize count and record the winner in a single round‑trip. A single Redis node comfortably handles >20 000 concurrent operations; sharding or clustering can be added for larger scales.

Gift Distribution Rate Limiting via Message Queue

When a user wins, the lottery service should not call the gift service synchronously for every win. Instead, it publishes a winning event to a message queue (e.g., Kafka, RabbitMQ). A small pool of gift‑service instances consumes the queue at a controlled rate (e.g., 100 messages / second), smoothing the downstream load and keeping MySQL write pressure low.

Overall Design Summary

The key principle for high‑concurrency lottery, flash‑sale or red‑packet systems is to eliminate the majority of useless traffic at the load‑balancer (≈99 %). The remaining 1 % of traffic is processed by a lightweight backend that uses Redis for the core draw logic and a message‑queue‑based rate‑limiting layer for expensive downstream operations such as gift fulfillment.