Business System Architecture Design: An Engineer's Guide to Game Event Systems

In addition to solid professional knowledge and extensive coding experience, a good software engineer should also possess sound architectural design thinking. Architecture can be divided into physical infrastructure design (operations) and logical software design. This article shares ideas and experiences on business system architecture design, using the 37 Platform special event system as a case study.

Why create special events? In game operations, the core metrics are user count and revenue. Special events are the most effective way to quickly achieve operational KPIs. They can be classified into eight types: brand, platform, channel, new‑user acquisition, re‑engagement, recharge, consumption, and activity.

Characteristics of special‑event business

1. Diverse functional forms – operators combine modules such as lottery, gift claim, quizzes, and bullet screens to stimulate payment and improve user experience.

2. Short development cycles – events are time‑limited, requiring strict launch deadlines. Rapid delivery (e.g., opening a server a day earlier) can provide a competitive edge.

3. High risk‑control requirements – especially when cash or high‑value prizes are involved, the system must be error‑free.

Three major features of special‑event business

1. Functional form diversity

2. Short development cycle

3. High risk‑control requirements

Three architectural tools for the business

1. Core feature componentization – Abstract each event into one or more “features” (e.g., a lottery feature that handles prize pools and free‑draw rules). By building a feature library, developers can compose complex events by mixing and matching features, avoiding duplicated logic.

2. Hook (AOP) concept – When a special rule is needed that deviates from the generic feature (e.g., a lottery rule that depends on platform level and game level), hooks allow developers to inject custom logic at predefined points without rewriting the whole feature. This enables extensibility and can be extended to a plugin mechanism.

3. Message middleware – Decouple modules and smooth traffic spikes by using asynchronous queues. In the 37 Platform event system, Redis List is used as a lightweight message broker. When users grab a red‑packet, the front‑end returns an immediate result while the backend processes persistence and delivery asynchronously, converting burst traffic into steady processing.

These three tools—componentization, hooks, and message middleware—address the three characteristics of special‑event business (diverse forms, short cycles, high risk control). They improve development efficiency, reduce QA workload, and lower operational risk.

Beyond the three tools, configuration management further enhances flexibility. The architecture can evolve with new requirements, and alternative implementations (dynamic proxies for hooks, professional MQ products for messaging) may be adopted based on cost‑benefit analysis.