Media event pipeline

A worked example: a streaming media business builds a high-throughput event pipeline and weighs queue-first against log-first architectures.

Docs / Examples / Media event pipeline

Media event pipeline

WaveStream streams video to millions of viewers. Every play, pause, and quality switch generates an event, and the team is building a platform that turns those events into real-time analytics, billing, and personalization. They already run RabbitMQ for a handful of internal queues, but the new pipeline needs to absorb far more volume with replay and strict ordering.

📡 Media & Streaming 🏷️ Event Streaming Platform 🎯 Million-scale events/sec

Step 1 · Learn the domain

In Domain Context Learner, WaveStream captures:

Prompt Answer
DomainMedia & Streaming
Qualities that matterScalability, Resilience & uptime, Cost control, Time-to-market
Data volumeHigh — every play, pause, and quality switch
Real-time needsHigh — analytics and personalization must react live
Integration complexityComplex — analytics, billing, personalization, support
Sensitive dataNot sensitive — viewing telemetry, no PII required

The profile pushes Architect toward scalability and resilience first, with cost efficiency ranked above compliance — telemetry, not regulated data.

Step 2 · Evaluate the architecture

In Architect, WaveStream opens the Event Streaming Platform scenario. With scalability and reliability weighted highest, the race is between the log-first and pub/sub-first patterns:

Architecture Why it ranks well here Watch out
Apache Kafka Log-based replay, per-partition ordering, massive throughput Operational complexity to host or manage well
Amazon Kinesis Data Streams Managed log semantics with ordering and replay Cost at sustained very-high throughput
Google Cloud Pub/Sub Fully managed pub/sub, at-least-once delivery Weaker ordering guarantees than a partitioned log
Amazon EventBridge Simple routing and filtering between consumers Not built for replay-heavy, event-log workloads

Because replay and ordering carry real weight, the log-first patterns lead the ranking. The interesting decision is managed vs self-hosted: if WaveStream's team can operate Kafka, its cost profile wins at this scale; if not, Kinesis trades cost for operational simplicity. That is exactly the tradeoff the What-If sliders make visible in one move.

⚖️

The Q&A panel spells out the log-vs-queue differences in plain language — ordering and replay semantics are the two dimensions that separate these architectures.

Step 3 · Review the design you have

WaveStream's current pipeline is built on RabbitMQ fan-out. Running it through Reviewer against the same scenario exposes the gaps:

Finding Why
Low fit on replayMessages are consumed and gone — no durable re-read
Low fit on ordering at scaleBroker-wide ordering collapses once consumers fan out
Low fit on throughputSingle-broker design needs heavy tuning at event-scale
Strength: operational simplicityWell-understood broker, easy to run today

The verdict is a clean justification for the migration: keep the RabbitMQ usage where queues genuinely fit, and stand up a log-first event backbone for the analytics, billing, and personalization consumers that need replay and ordering.

Want the full workflow before the examples? Read the Wahab Waypoint overview →

← Back to all docs