Designing a Scalable Multi‑Game Live Streaming Architecture: Room & Gameplay Services Explained

Introduction

Duoyuan is a matchmaking live‑streaming product that originally used a three‑person video link (matchmaker + male and female guests) for online interaction. To enrich user experience, increase stickiness, and create more paid scenarios, multi‑person rooms (e.g., 7‑person rooms, games) were introduced. However, early designs required closing and reopening rooms to switch modes, harming user experience. A new "gameplay room" concept was created to allow hosts to switch gameplay modes without disrupting the room.

Business

The core concept is the "live room". Similar to a tabletop role‑playing game, the host creates a room and users can choose different scripts (gameplays). The room provides the venue, while various gameplay configurations act as different scripts.

Service Division

By analyzing gameplay and room business logic, rooms are abstracted as a foundational service used by all gameplay services. In the architecture, room service and gameplay service are peers: room‑related interactions go directly to the room service, while gameplay‑related interactions go to the gameplay service.

Room Service

Previous designs conflated rooms with gameplay, limiting extensibility. The new room service abstracts basic capabilities shared by all room types, such as:

Room lifecycle management (open/close)

Basic information (ID, background, announcements, user list)

Relationship management (mute, kick, blacklist)

Permission verification (different host levels)

User entry/exit handling

Link Mic (连麦)

Application flow: user request → matchmaker approve/reject → invitation

Data maintenance: timestamps, stream IDs for statistics

Status maintenance: host info, live‑room ID, user profile, used for recommendations, etc.

Audio‑video push/pull streams: callbacks trigger business logic on mic up/down events

Gameplay Service

Gameplay Definition

Examples include KTV singing, wish‑based auctions, casual chat topics—essentially various game rules and formats.

Module Overview

Gameplay role management

Gameplay configuration (host settings)

Gameplay data maintenance (real‑time state)

Gameplay process management (start, pause, end)

Gameplay Entity Interface

type PlayGame interface {
    Config(ctx context.Context, opt *ConfigOption)      // configuration
    LiveInfo(ctx context.Context, opt *RoomInfoOption) // all data
    Assignment(ctx context.Context, opt *CheckOption) // role assignment/cleanup
    Play(ctx context.Context, opt *PlayOption)        // start round, set content
    EndGame(ctx context.Context, opt *EndOption)      // end round
}

Gameplay API Distribution

A factory pattern creates specific gameplay instances, isolating them from each other.

Client‑Server Data Sync

Because gameplay data changes frequently, a push‑pull hybrid model ensures consistency and timeliness, avoiding heavy client polling.

Full sync occurs when switching gameplay or on first entry; incremental sync handles role changes, round transitions, and state updates.

Gameplay Management

A manager coordinates switching logic and maintenance across different gameplay modules.

Interaction Between Gameplay, Room, and Client

The overall interaction flow is illustrated below.

Wish Gameplay (心愿玩法)

Introduction

Rules

The wish gameplay mimics an offline auction: participants apply to go on mic, set an item, the host announces, and viewers bid by sending specific gifts. The system records real‑time rankings; the auction ends when no further bids are placed or the host closes it.

Role Definitions

Host: controls the auction flow

VIP: invited guests who can go on mic directly

Hot Seat: top six bidders automatically granted mic access

Auctioneer: any user who puts an item up for auction

Audience: regular viewers

Client Communication Protocol

{
    "type":0, // 0: full update, 1: set complete, ...
    "setting":0,
    "auction_result":1,
    "data":{
        "live_id":"145234542352",
        "record_id":"15634524542_1",
        "state":0,
        "ontice_title":"",
        "notice":"",
        "lot":{
            "goods":"buddy",
            "expire":1800,
            "gift":{
                "id":10,
                "name":"比心",
                "icon":"",
                "price":100,
                "icon":"http://img.boluohuyu.cn/MTU2Mjk5OTgzNTcwNSMgMzYjcG5n.png",
                "gift_continue":1,
                "gift_animation":1
            }
        },
        "role":{
            "host_list":[{"uid":1222,"nick":"竞拍榜1","portrait":"","gender":1}],
            "owner":{"uid":1222,"nick":"竞拍榜1","portrait":"","gender":1},
            "host":{"uid":1222,"nick":"竞拍榜1","portrait":"","gender":1},
            "v1":{"uid":1222,"nick":"贵宾1","portrait":"","gender":1},
            "v2":{"uid":1222,"nick":"贵宾2","portrait":"","gender":1},
            "v3":{"uid":1222,"nick":"贵宾3","portrait":"","gender":1},
            "auctioneer":{"uid":1222,"nick":"拍卖人","portrait":"","gender":1},
            "bidder":[{"uid":1277,"nick":"竞拍榜1","portrait":"","gender":1,"score":90,"light_level":0}],
            "lock":{"host":1}
        }
    }
}

Interaction Sequence Diagram

Gameplay Effect Screenshot

Summary

The new architecture separates room and gameplay services, providing a solid foundation for future extensions. It resolves previous pain points such as client‑side room state inconsistencies, heavy polling for rankings, and tangled codebases. By moving mic control to the server and using message‑driven synchronization, the system achieves clearer code structure, better scalability, and a smoother user experience when switching gameplay without leaving the room.