Reactive Infrastructure for Live Events with Momento and Valkey
Reactive infrastructure powered by Momento and Valkey turns a CDN-scale event stream into user-facing changes in seconds.
Media experiences are becoming more dynamic and compelling as services increasingly respond to playback issues and adapt to viewer behavior in real time.
Reactive infrastructure describes this common pattern of connecting incoming observations to changes in the viewer experience. Specific capabilities like feed personalization, quality of experience monitoring, and anti-piracy detection each touch different parts of a live media system, but all of them transform some type of client activity into timely decisions.
The shared challenge begins with ingesting dynamic CDN-scale traffic without a CDN. Televisions, browsers, and mobile devices send observations directly to a collection endpoint. Audience surges become ingestion surges, and every accepted event creates work beyond that endpoint. And collecting the data is only the beginning! That raw data must become useful and be delivered for use elsewhere within seconds.
A four-stage pattern organizes that work: ingestion → processing → storage → decisioning. The stages adapt to each use case through the signals they collect, how they group data, the stores they use, and the decisions they drive. Their distinct responsibilities help identify the most important design choices at each stage.
How the four stages close the loop
Reactive architecture forms a closed loop from an observation on the client, through the data pipeline, and back to a change in the client experience. That change then produces new observations, and the cycle begins again.
The four stages of this architecture are:
- Ingestion accepts client events and shapes the incoming traffic.
- Processing organizes event fragments into an orderly, validated stream.
- Storage makes that data available for analysis in forms suited to its consumers.
- Decisioning connects the resulting information to product behavior.
A common four-stage pattern connects client activity to decisions that affect the media experience.
The cloud components for each stage focus on those specific responsibilities. An internet-facing gateway receives beacons from clients. Valkey (the community-backed fork of Redis) provides a shared collecting pool behind it, with lightweight functions and connectors preparing data for downstream stores. Decision consumers use relevant information to influence the experience through business logic, an edge function, or an operator action.
Note that the diagram’s Gateway or CDN path represents the outbound, or egress, direction that delivers the experience to viewers. This complements the inbound, or ingress, path through which client observations enter the architecture.
Data flows through this architecture from ingestion towards decisioning, but the design process should actually work backwards from the decision it drives. What signals does that decision require? How quickly must it affect the experience? How much data loss is tolerable? Those answers shape the choices at every stage.
Ingestion shields downstream services from client traffic
The ingestion stage is the interface between your infrastructure and millions of viewers. Its gateway must handle connections from devices across the open internet, absorb sharp changes in traffic, and prevent that volatility from overwhelming internal services.
HTTP beacons are the delivery vehicle for signals that eventually drive decisions about what the user experiences. Beacon size and frequency directly affect load on the gateway. Choose the signals needed for the decision to keep each payload small. Set the beacon period according to how quickly the decision needs new observations, so the system receives useful updates without collecting more than it needs.
The gateway controls how that traffic safely reaches the backend. It holds incoming events briefly and forwards them together, converting a firehose of individual requests into more manageable micro-batches. By reshaping the flow of data, the gateway protects downstream infrastructure and reduces the need for defensive overprovisioning.
The brief delay for micro-batching is a negligible component of end-to-end latency when the buffering period is small relative to the decision’s latency budget, but it slightly increases the opportunity for data loss. Buffered events have just one copy, so if a gateway node fails before forwarding them, they will be lost. Ultimately, batching policy trades a slight increase in exposure to data loss for significant gains in overall reliability and lower infrastructure costs.
Momento Valkey Router contributes connection pooling, authentication, throttling, and shard-aware routing at this boundary. These mechanisms support the gateway’s shielding role alongside the architecture’s beacon batching. Reusing backend connections lets the collecting tier serve a much larger device population without maintaining a separate upstream connection for every client.
Batch and control traffic at the gateway within the decision’s latency and loss budget so downstream capacity supports useful work.
Processing organizes events and routes them to consumers
Batches arrive through different gateway nodes, leaving fragments of related activity in separate buffers. Processing brings those fragments into common, replicated collecting pool powered by Valkey and prepares them for downstream use. Lightweight functions and asynchronous connectors handle transformation and routing.
A stream identity is defined by some property of a beacon, like a session id or a geographic region. The stream key directs related events towards the appropriate shard, where the fragments are assembled into an orderly stream. This organizing phase presents downstream consumers with a coherent sequence of related activity, ready for storage and analysis.
Keep preparation lightweight at this stage. Validate records before they reach live consumers, make small adaptations to their shape, and route them to suitable sinks. Expensive joins, exploratory queries, and complex analysis belong with the downstream systems chosen for that work. Keep a raw archive independent of live validation so malformed records remain available for inspection or replay.
Momento’s lightweight WASM functions perform these short validation and transformation operations in batches. Its asynchronous sink connector drains Valkey and flushes complete files to destinations such as S3, separating that transfer work from client requests.
Collate, validate, and route events without turning the high-volume processing tier into an analytics engine.
Storage serves each consumer
Once events are organized, the next question is how they will be used. Storage serves those consumers’ access patterns, rather than asking one database to handle every question. Query shape, required response time, and retention can differ substantially even when consumers use the same underlying event flow.
QoE monitoring illustrates this perfectly. Automated alarms that should trigger within seconds use rolling counters in Valkey. Meanwhile, an operator investigating an incident needs an analytical store such as ClickHouse to perform ad hoc queries in less than a minute. On the side, events are funneled to an S3 archive in Parquet for retrospective analysis, replay, and auditing. A bounded counter lookup, an exploratory query, and a historical scan each place wildly different demands on storage.
Personalization changes the query shape again. Similarity retrieval against user and content representations calls for vector-oriented storage. The architecture keeps the same storage responsibility while choosing a different representation and retrieval mechanism. The particular stores follow the consumer’s requirements.
Valkey serves both collection and fast operational storage roles. Those roles can share a tier, while performing different work. The asynchronous connector introduced in processing gives archival storage its own transfer path, while live consumers use views prepared for their needs.
The time to read a counter or run a query is only one part of the time from client activity to an applied outcome. The beacon period, buffering, preparation, and decision timing also contribute. Selecting a fast store cannot compensate for a pipeline that delivers the needed information too late.
Choose and combine stores according to each consumer’s query, timeliness, and retention needs.
Decisioning applies results without blocking the experience
Decisioning connects prepared information to actions in the media system. A decision consumer, such as a policy engine or operator, evaluates that information and chooses an action. Product business logic or an edge function applies the result to rankings, delivery paths, session policies, or other application behaviors.
Keep the analytical workload off the live serving critical path. Requiring a complex query for each viewer request ties the product’s response time and availability to that query system. Compute decisions outside the viewer-request path and make the results available to the request-handling logic. That logic applies the result without waiting for a fresh analytical query on each request. Choose how often to update the decision according to the outcome it must affect.
Anti-piracy detection illustrates the timing relationship. Policy analysis runs between segment requests, with a result available for subsequent enforcement. That provides decision time without adding the same analytical work to each segment response. Existing access authorization remains part of the delivery system.
Personalization offers another reason for deliberate timing. Continuously updated interest data need not produce a different ranking on every refresh. Keep the published ranking stable while the underlying analysis continues. In both cases, the decision update frequency reflects what the experience needs.
Once the product applies a decision, subsequent client observations reveal its effects. Those observations return through ingestion, starting the cycle again.
Apply decisions at the pace the outcome needs while keeping analytics off the serving critical path.
Adapt the architecture to the decision
The four stages in this reactive architecture work together to convert CDN-scale observations into user-facing changes within seconds.
Gateway batching reduces request overhead before internal services receive the data. A collection pool assembles related activity into orderly streams sent to an appropriate datastore for each downstream consumer. Analytics engines then turn that information into decisions, which are applied through application business logic to impact the user experience.
Feed personalization, QoE monitoring, anti-piracy detection, and other use cases can all leverage the same architecture with slight adaptation. Remember to start with the outcome, then work backwards through the architecture to apply decisions and propagate constraints. The loop becomes reactive when the data changes what the user experiences.
Building systems that handle CDN-scale traffic without a CDN is challenging, even when you’re an expert. Momento engineers understand how systems fail in mission-critical situations, and designed the Momento platform to handle millions of requests per second. It has powered live experiences during the Football World Cup, the Super Bowl, and other global media events across leading providers like FOX, Paramount, and Warner Bros. Discovery.
Chat with us if you’d like to explore making your product more reactive!