From Copy‑Paste to Scalable Lottery Platforms: A Backend Engineer’s Guide

Requirement: Lottery System

If you receive a request to develop a lottery activity backend, the usual first step is to create a new project, design the database and APIs, and start coding. When a similar request arrives later, many developers simply copy the previous project and modify it, which looks efficient but is actually a poor practice.

Reflection: What Went Wrong

Copy‑paste development leads to low code reuse, duplicated testing and deployment pipelines, scattered data, and tightly coupled private systems that cannot be offered as a SaaS solution.

To avoid these issues, the business system should be abstracted into a business platform that provides common processes, while special workflows remain in separate services.

Common Business

Designing a platform requires identifying truly generic logic that can be shared across multiple lottery activities.

Generality

The goal is to support many possible business scenarios on the platform. By analyzing existing and future requirements, extract reusable logic and avoid over‑engineering.

Example: An activity may have multiple sessions, each with its own prize set and schedule. This requires a separate session dimension in the database.

Example: Prize redemption methods (physical delivery vs. code) dictate additional fields such as shipping address and contact information.

Boundary Handling & Business Splitting

Determine which logic belongs to the platform (e.g., prize configuration) and which is specific to a particular business (e.g., user ranking).

Sharing functionality (e.g., share‑to‑gain‑extra‑draw) can be extracted into a separate Share Platform that other services can reuse.

Complex reward mechanisms may require a Task Scheduling Platform to manage triggers and rewards.

Data Handling

Large‑Scale Storage

Because the platform will accumulate large volumes of data, horizontal sharding should be considered. Below is a simple sharding example.

func GetTableNameByActivityId(activityId int64) string {
    if activityId > 0 {
        return "activity_prize_redeem_" + strconv.FormatInt(activityId%16, 10)
    }
    return "activity_prize_redeem"
}

Select an appropriate shard key to ensure balanced data distribution and efficient queries.

High‑Performance Queries

Use caching (Redis), message queues, and Elasticsearch for high concurrency scenarios.

Operational Metrics & Reporting

Design tables to capture key metrics needed by product and operations teams, such as per‑platform participation counts.

Log & Operation Record Table

Persist important operation records in a dedicated table.

go service.Record(&models.SysOperateRecord{
    BizType:    dao.BizType_Customer,
    OperType:  dao.OperType_INSERT,
    OperContent: fmt.Sprintf("batch insert one new customer: %s", customer),
    Operator:   userinfo.Id,
    CreateTime: currentTime,
    UpdateTime: currentTime,
})

Platform Management

Class‑SaaS Isolated Environments

Provide each user with an isolated namespace and app ID to separate data and configurations.

Unified Multi‑Platform Management

A central admin console can create namespaces, configure each sub‑platform (lottery, share, task), and handle updates, deletions, and statistics.

Technical Selection

Microservices

Microservice architecture supports business expansion, independent deployment, and unified management via API gateways, configuration centers, and service discovery.

Business‑Driven Architecture

Concurrency, stability, third‑party integrations, and inter‑service communication (message queues, scheduled tasks) dictate architectural choices.

Performance

If performance is critical, a monolith may be faster, but microservices can still meet performance goals through profiling, caching, and scaling.

Deployment Model

Adopt CI/CD pipelines, containerization (Docker), and orchestration (Kubernetes) for blue‑green deployments, rollbacks, and auto‑scaling.

Security Considerations

Business Security

Protect the lottery prize flow with game‑logic validation, captchas, and blacklist controls.

Web Security

SQL injection prevention via ORM or parameterized queries.

CSRF protection using framework‑provided tokens.

XSS mitigation through output encoding.

Enforce HTTPS.

Strict permission checks.

Password hashing (bcrypt, salted MD5) and encryption for sensitive data.

Conclusion

By considering business, data, technology, and security holistically, developers can transform a simple lottery service into a reusable platform, gaining long‑term benefits and advancing their engineering skills.