How We Evolved the Voice Chat Room Architecture to Scale with Real‑Time Interaction

Background and Evolution Phases

Voice‑chat rooms (语聊房) were built on top of an existing live‑streaming platform. The initial one‑to‑one interaction model limited the product to a single host‑to‑host or host‑to‑audience session. Two major phases drove the architecture:

Exploration (July 2022) – Added multi‑host video PK and host‑to‑audience audio/video to match competitors.

Strategic Upgrade (2023) – Became a dedicated product with faster iteration, higher quality expectations, and the need to support both host‑to‑host and host‑to‑user interactions.

Live‑Streaming Stack

Typical pipeline:

Capture : acquire raw video/audio from devices.

Encoding : compress with H.264/H.265.

Streaming : push via RTMP/HLS/DASH to a video‑cloud service.

Transcoding : generate multiple resolutions/bitrates.

Distribution : CDN delivery.

Playback : client pulls stream.

P0 API : returns stream URL, quality, orientation, etc.

P1 API : returns room metadata (title, announcements, gifts, etc.).

Real‑Time Communication (RTC) Model

To enable true multi‑host conversations the system introduced three abstractions:

Session : logical container created by a host; can invite multiple other hosts.

Conversation : media exchange for a single participant within a session.

Channel : RTC resource identifier that maps one conversation to a unique channel ID.

When a host starts a session the client creates an RTC channel for each invited host. The session persists even if the creator leaves, allowing remaining participants to continue.

Bypassing the Video‑Cloud Path

The team evaluated a direct‑viewer‑to‑RTC approach. Although feasible and used by many interactive live rooms, it would double the state‑synchronisation burden because both the RTC system and the video‑cloud pipeline would need to stay consistent. The decision was to retain the video‑cloud path for reliability and lower implementation cost.

Extension to Audience Participation (B2C)

Initially only PC‑based hosts could use multi‑host RTC. To involve mobile clients and audience‑initiated streams the architecture added:

Bidirectional audio/video between audience and hosts.

Mic‑seat management (mute, kick, speaking status).

Gift flow from audience to interacting users.

Two user states were defined:

Audience State : receives only the mixed video‑cloud stream (which already contains the combined RTC audio).

Interactive State : joins the RTC channel directly, sending and receiving audio without pulling the video‑cloud stream.

Mic‑Seat Management Migration to Backend

During the exploration phase the maximum concurrent seats were 5 × 5 = 25, manageable on the client. After scaling to larger rooms the client‑side logic could not handle complex allocation rules, prompting a migration of mic‑seat state to a dedicated backend service. Migration steps:

Expose a transparent channel for B‑side clients to push seat updates to the server.

Version data structures so old clients continue using the legacy format.

Define compatibility matrix (old server ↔ new server, old client ↔ new client) and test each combination (e.g., old server + new client, new server + old client, etc.).

Role‑Based Access Control (RBAC)

Permissions for hosts, admins, and audience members were modelled as:

User : actor (B‑side host or C‑side viewer).

Role : aggregates multiple permissions; a user may have several roles.

Permission : concrete actions such as mic‑control, gift handling, or gameplay management.

Real‑Time State Synchronisation Strategy

With mic‑seat data moved to the server, update volume grew dramatically (millions of concurrent users in hot rooms). The team adopted a hybrid approach:

Full state push over long‑lived TCP/WebSocket connections (millisecond latency, best‑effort delivery).

Push‑pull fallback via HTTP polling when the long‑lived channel is unstable (second‑level latency, higher server load).

Gateway‑level in‑memory cache to aggregate identical room requests and reduce backend pressure.

Embedding lightweight SEI messages in the video stream for non‑critical users (≈10 s latency, negligible overhead).

Client‑side versioned ordering to prevent out‑of‑order consumption.

Monitoring, Testing, and DevOps Practices

A layered monitoring stack was introduced:

Infrastructure metrics (CPU, memory, network).

Request‑level metrics (QPS, latency, success rate).

Business‑level metrics (funnel conversion, state transitions).

Operational safeguards include:

CI/CD pipelines with static code analysis.

Automated integration tests covering critical scenarios.

Performance guard on key interfaces (e.g., P999 response time).

Daily health checks and automated incident triage.

Key Technical Numbers and Decisions

Maximum concurrent mic seats in early design: 5 × 5 = 25.

State‑sync latency targets: full push ≈ ms, push‑pull ≈ seconds, SEI fallback ≈ 10 s.

Performance guard metric: P999 response time must stay within defined SLA.

Summary of Architectural Trade‑offs

Retaining the video‑cloud pipeline preserves content‑safety delay handling and simplifies consistency at the cost of an extra hop for viewers.

Migrating mic‑seat logic to the backend improves scalability and feature extensibility but introduces real‑time sync pressure, mitigated by hybrid channels and caching.

Introducing RBAC centralises permission checks, enabling fine‑grained control for hosts, admins, and audience participants.

Code example

相关阅读：