Design and Implementation of a Scalable Generic Lottery System

Background – Marketing activities often require various lottery‑style games (spinning wheels, red‑packet rain, slot machines, shake‑to‑win, etc.) with frequently changing and highly customized requirements such as per‑user probability variations, daily prize‑quantity limits, and anti‑cheat time‑window controls. Early solutions involved ad‑hoc development for each demand, which became unsustainable as the volume and complexity grew.

System Overview – To address these challenges, a generic lottery system was built as an independent, reusable service that can be deployed and maintained separately. The system follows Domain‑Driven Design (DDD) to abstract business concepts into distinct domain models.

Domain Model – Core entities include Activity (the lottery campaign), Round (multiple rounds per activity), RoundPrize (prize‑per‑round with its own probability), ProbabilityGroup (sets of probability rules), WinningRule (e.g., “3 attempts, win at most once”), AntiCheatRule (user‑ or time‑based restrictions), and CallbackRule (asynchronous notifications). The model is illustrated in the article’s diagrams.

Implementation Process – Each entity is exposed via an interface and instantiated through a factory that selects the appropriate concrete class based on type attributes. A custom distributed real‑time memory cache reduces database round‑trips for high‑frequency reads. The lottery flow consists of five steps: pre‑validation (Redis‑based rule, risk, and inventory checks), execution of the lottery algorithm, post‑validation (final inventory verification), persistence (transactional DB write with locking), and result return (real‑time and asynchronous).

Probability Algorithms – Three cases are handled: (1) total probability equals 1 (guaranteed win), (2) total probability less than 1 (partial win with a “no‑win” interval), and (3) total probability greater than 1 (always win, weight calculated as P_i/(ΣP)). The article provides numeric examples and illustrates each case with diagrams.

Extensibility – Business objects include a type field and use the Strategy pattern. New requirements (e.g., date‑based inventory) are supported by adding a new subclass without altering existing logic, achieving roughly 90 % configurability and 10 % lightweight code extensions.

Concurrency Control – The system has withstood high‑traffic events (e.g., automotive expos with tens of thousands of QPS). An API gateway performs rate‑limiting; Redis stores per‑user eligibility, attempt counts, and anti‑cheat data; a local cache with MQ‑driven refresh ensures fast access to rarely‑changed prize configurations while keeping them up‑to‑date.

Lottery Management Backend – A separate Vue‑based admin console allows product and operations teams to create/edit activities, configure prizes and probabilities, and manage records without developer involvement. A library of ready‑made front‑end components (spinning wheel, red‑packet rain, etc.) can be dropped into any UI by referencing the activity ID.

Overall Architecture – The article presents a full‑stack diagram showing the gateway, backend services, Redis, database, MQ, and UI components, illustrating how each layer interacts to provide a scalable SaaS‑style lottery platform.

Conclusion – Within a year the system has supported hundreds of campaigns, tens of millions of draws, and achieved stable operation. It delivers configurable probability groups, winning and anti‑cheat rules, flow control via gateway, Redis‑backed fast checks, and a modular SaaS architecture that enables near‑zero‑code reuse across multiple business lines.