Design of a Bus‑Style Service (Pigeon) for Flexible Activity Composition in Live Streaming

The article discusses the challenges of assembling reusable services for live‑streaming activities, where a functional module finishes execution and needs to trigger subsequent actions that should be configurable rather than hard‑coded.

To address this, the authors propose a bus‑style service called "Pigeon" that acts as a routing layer. Each subsystem (e.g., task system, progress‑bar system, reward system) sends a data packet to the Pigeon service after completing its lifecycle. The Pigeon service looks up a configuration (the "pigeon config") and forwards the packet to the appropriate downstream subsystem, enabling flexible, configuration‑driven composition without code changes.

Overall Architecture

Fulfillment capability – trigger actions after a module ends.

SDK integration – provide an interface‑level wrapper with autoconfiguration.

Global identifier dictionary – a unified set of field names (e.g., userId, anchorId) shared by all participants.

Automatic registration – services register themselves with the Pigeon service upon SDK startup.

The routing can be synchronous or asynchronous; the implementation prefers asynchronous delivery via RocketMQ. Failed deliveries are persisted for retry.

SDK Details

When a subsystem includes the SDK, a PushConsumer bean is automatically created in the Spring container, listening for messages labeled "fly". The consumer parses incoming messages and dispatches them to the appropriate functional modules (S1, S2 … SN).

Automatic registration works by periodically scanning annotated classes, extracting their type information, and pushing registration data to the Pigeon service.

Comparison with ESB

The Pigeon service is positioned as a lightweight, asynchronous "dumb pipe" for short‑term activity modules, whereas traditional ESB solutions are heavyweight, protocol‑centric, and suited for large‑scale, long‑lived enterprise integrations. The table in the original article highlights that Pigeon excels in rapid activity development but has limited capabilities for large IT system integration.

Comparison with Pipeline

While pipeline patterns are common in CI/CD, network byte‑stream processing, and workflow engines, Pigeon focuses specifically on the tail‑end fulfillment of activity flows, leaving core process orchestration to other systems.

Forwarding Capability

The Pigeon service can forward messages in three ways:

Custom business routing – clean and transform raw messages before forwarding.

Automatic distribution – forward based on topic tags, allowing consumers to selectively pull messages.

Message storage – persist important messages (e.g., gift events) in TiDB for later replay.

Performance tests show that with 32 Docker containers on an 8U16G server, the service can handle up to 3 million messages per minute while keeping CPU usage around 45%.

Future Outlook

The authors envision integrating Function‑as‑a‑Service (FaaS) for more flexible message cleaning and combining BaaS for storage, aiming for a cloud‑native, globally distributed solution.

Overall, the article provides a practical, engineering‑focused design for a configurable, bus‑style event routing layer that improves development efficiency and reduces code duplication in live‑streaming activity scenarios.