DEV Community: Andrei

Building fair real-time odds for CS2 Twitch stream predictions

Andrei — Thu, 19 Mar 2026 19:46:19 +0000

In my last post, I wrote about stream delay and why realtime on Twitch is secretly a timeline problem.

This time: odds.

I am building elo.market, a live prediction system for CS2 streams. Viewers bet virtual elo on things like round winners, bomb plants, and clutches.

At first, dynamic odds sounded easy.

Votes come in -> odds move.

Done, right?

Not really.

Because if odds move too slowly, the market feels fake.

And if they move too fast, one smart whale can make the whole thing feel rigged.

The Problem In One Line

This was the failure mode I kept running into:

small early vote -> juicy odd appears -> whale grabs it -> market feels broken

Or visually:

+------------------+     +--------------------+     +------------------+     +------------------+
| Small early vote | --> | Big price appears  | --> | Whale takes it   | --> | Everyone else    |
| from normal user |     | on the other side  |     | before it settles|     | thinks: "lol ok" |
+------------------+     +--------------------+     +------------------+     +------------------+

That is technically a dynamic market.

It is also terrible product design.

The First Version Was Too Naive

My first version was basically:

start from some base probability
add a seed so the first bet does not nuke the market
recalculate odds from the current pool

Conceptually:

adjustedProb = (amountOnOutcome + baseProb * seed) / (totalPool + seed);

That was fine as a first step.

But it had two problems.

First, some markets should not even start 50/50.

A round_winner market is not actually even if one side is broke and the other has rifles.

So I started feeding real game context into the base probabilities:

loss streaks
score momentum
streamer economy as a team signal

That helped the opening price feel smarter.

But it still did not solve the whale problem.

The Whale Problem

The obvious model is amount-based.

More money on one side means the odds shift harder.

Sounds fair, until one large bet starts overpowering the market.

So I tried blending two signals:

how much money was bet
how many people bet that side

That was better, but my first attempt still had a bug in the idea.

I used average bet size in the formula.

Which meant a whale did not just affect the amount part. They also inflated the "crowd consensus" part by making average bet size bigger.

That was dumb.

I accidentally gave large bets influence twice.

The Fix That Actually Mattered

The best change was surprisingly small.

I stopped using average bet size for voter influence and switched to a fixed vote unit instead.

So the logic became:

effectiveAmount =
  (1 - voterWeight) * rawAmount +
  voterWeight * voterCount * FIXED_VOTE_UNIT;

That changed the feel of the market a lot.

Now a whale can still move odds because size should matter.

But they cannot also pretend to be "the crowd" just because their bet was huge.

That one change made the system feel much less abusable.

Then I Hit The Next Problem

Even with a better formula, fixed seeds still broke at different economy sizes.

If one streamer has average bets around 50 elo and another has average bets around 1000, the same seed value behaves completely differently.

So I made the seed scale with season behavior instead of hardcoding it.

Conceptually:

dynamicMinSeed = seasonAvgBet * 50;
effectiveSeed = max(dynamicMinSeed, totalPool * seedMultiplier);

That made early odds much harder to snipe across both small and large channels.

Not Every Market Should Behave The Same

Another lesson: a bomb prediction and a map-wide prediction should not react with the same personality.

So I ended up with templates.

dynamic for markets that can move more
balanced for standard round predictions
stable for short live windows
anchored for longer markets that should respect the opening line more

That was much better than pretending one formula could fit everything.

Delay Came Back Again

And because Twitch loves making every problem slightly worse, delay showed up here too.

If I delayed both PREDICTION_CREATED and ODDS_UPDATE the same way, viewers saw stale odds.

So the final model became:

delay the prediction event
send odds updates immediately
buffer them on the client until the prediction is actually visible

That way, when the card appears, viewers see current odds instead of ancient history.

Fairness Needed One More Layer

Even after all that, there was still one ugly edge case:

the user clicks at one price, but by the time the vote reaches the backend, the odds are worse.

So I added slippage protection.

If the odds move too far against the user, the vote is rejected and the UI can ask them to accept the new number.

That turned out to matter almost as much as the formula itself.

Because fair pricing is not just math.

It is also about whether users feel tricked.

Where I Landed

The current system is basically this:

game state priors
      +
adaptive seed
      +
voter consensus
      +
slippage protection
      +
delay-aware delivery
      =
dynamic odds that still feel fair

smarter base probabilities from real game state
adaptive seed so early votes do not create nonsense
voter weighting so one whale does not dominate instantly
fixed vote units so big bets do not fake consensus
different templates for different market types
slippage protection for bad fills
delay-aware delivery so live odds still look live

The funny part is that dynamic odds sounded like a tiny feature when I started.

In reality, it turned into a product trust problem.

If the odds feel fake, people stop caring.

If the odds feel exploitable, people stop trusting.

The goal was not "perfect market making."

The goal was simpler:

make odds move enough to feel alive, but not enough to become a farming strategy for whales.

If you have built low-liquidity markets, game economies, or live pricing systems, I would love to hear what tradeoffs you made.

How I synced real-time CS2 predictions with Twitch stream delay

Andrei — Mon, 16 Mar 2026 01:14:39 +0000

I am building elo.market, a real-time prediction system for CS2 streams.

At first, this sounded simple: the game emits events, I create predictions, viewers vote.

Then I ran into the actual problem: my backend knew about round starts, bomb plants, and round ends before Twitch viewers saw them.

So this stopped being a "realtime UI" problem and turned into a timeline problem.

The hard part was not generating predictions.

The hard part was preserving a believable timeline for each viewer.

Because on Twitch, there is no single "the stream is delayed by X seconds" value.

There are at least two different delays involved:

the broadcaster's intentional stream delay
each viewer's personal playback delay caused by Twitch buffering, network conditions, device behavior, and low-latency mode

If you get this wrong, the whole product feels broken:

predictions open too early and spoil what is about to happen
predictions close before the viewer even sees the moment
odds update before the actual prediction card appears
late votes get rejected even though the UI still looks valid

I ended up building a two-layer delay system: part server-side, part client-side.

But the bigger lesson was this: delay was only the visible problem.

The deeper problems were:

event ordering
stale data
fairness in vote validation
keeping one backend timeline compatible with many viewer timelines

The Architecture

The event pipeline looks like this:

CS2 GSI -> Oracle -> Redis Streams -> Worker -> Redis Pub/Sub -> API SSE -> Frontend

The important bit is that predictions are created from real game events, not from the Twitch video stream.

That means the backend always knows about a round start or bomb plant before the viewer sees it on Twitch.

So I had to answer a simple question:

When should each viewer see each prediction event?

The answer became:

apply the streamer's configured broadcast delay on the server
apply the viewer's additional personal delay on the client

That split turned out to be much cleaner than trying to fully solve everything in one place.

The Real Problem Was Not Delay - It Was Causality

At first I thought I just needed to "shift events by X seconds."

That was naive.

What I actually needed was a system where the UI still made sense after delay was applied.

For example:

a prediction card should exist before its activity feed starts filling up
odds should not update for a prediction the viewer has not seen yet
a LIVE prediction should not appear after it has already resolved
the frontend and backend should agree on whether a vote is still valid

Once I started thinking in those terms, the architecture changed a lot.

Layer 1: Streamer Delay on the Server

Each streamer can configure a delay in seconds.

I use that value in the SSE layer and buffer most outgoing events before they are sent to clients.

Conceptually it looks like this:

const delayMs = streamerDelaySeconds * 1000;
const delayedEvents$ = streamerEvents$.pipe(delay(delayMs));

This handles the obvious case: if a streamer intentionally runs a 60-second delay, predictions should also arrive roughly 60 seconds later.

But this alone is not enough.

Two viewers can watch the same streamer and still be several seconds apart. One is on desktop with low-latency mode, another is on mobile with buffering, another is watching inside a Twitch extension.

So I needed a second layer.

The First Versions

Initially, I added a frontend control where viewers could manually configure their own extra delay.

It technically worked. It was also bad UX.

Most people do not want to think in terms of:

streamer delay
personal delay
countdown drift
whether they should add 3 seconds or 7 seconds

Even worse, negative adjustments were confusing. They mostly changed timers, not reality.

So while the manual control was useful for debugging and edge cases, it was clearly not a good primary solution.

Then I tried a semi-automatic calibration flow.

The system would wait for a real game event from the backend, and then ask the viewer to click when they saw that same moment on stream.

In one iteration, I used round end events for calibration: the backend knew exactly when the round ended, and the viewer clicked when they saw that same moment on stream.

This was much better than a raw slider because the user no longer had to guess.

But it still had problems:

it required active user participation
it was easy to miss the moment
calibration quality depended on reaction time
it felt like setup, which is never what you want in a live product

It was a useful bridge, but still not the end state.

The funny part is that the cleaner answer was sitting in Twitch's own APIs the whole time.

I just had not looked carefully enough at the docs.

On the web player side, Twitch exposes hlsLatencyBroadcaster through playback stats.

On the Twitch Extension side, a similar value is available through the extension context API.

So the final detection rule became simple:

userDelay = max(0, viewerLatencyToBroadcaster - streamerDelay)

That made the manual and click-to-calibrate flows much less important. They became fallback ideas, not the main path.

Measuring Delay Was the Easy Part

In the web app, I poll the Twitch player and read hlsLatencyBroadcaster. In the extension, Twitch pushes similar latency through its context API.

I still smooth the values with a rolling median and only apply meaningful changes, because raw samples jump around.

But honestly, delay measurement ended up being less interesting than what came next.

Why I Did Not Bake Delay Into Stored Timestamps

One of the most important design decisions was to keep timestamps pure.

I do not store delayed timestamps in the database.

createdAt, lockedAt, resolvedAt, and closesAt all remain real server-side times.

Delay is applied only at consumption and validation time.

That matters because different viewers can be on different effective delays for the same prediction.

If I had baked delay into stored timestamps, I would have mixed transport concerns with business state and made the whole system much harder to reason about.

Instead, delay is applied in a few explicit places:

SSE buffering on the server for streamer delay
client event queueing for viewer-specific delay
vote validation for grace periods
countdown rendering for display

That separation kept the model sane.

Not All Events Can Be Delayed the Same Way

At first glance, you might think: just delay every SSE event by the same amount.

That does not work.

Some events are structural:

PREDICTION_CREATED
PREDICTION_UPDATED
GAME_STATE_UPDATED

Those can be delayed safely.

But some events are highly dynamic:

ODDS_UPDATE
VOTE_PLACED

If I delayed those blindly on the server, viewers would get stale odds and activity could arrive for predictions they had not seen yet.

So I ended up with a hybrid approach:

most game-driven events are delayed server-side by streamer delay
ODDS_UPDATE and VOTE_PLACED are sent immediately
the client buffers them until the related prediction is actually visible

Conceptually:

const immediateEvents = ['ODDS_UPDATE', 'VOTE_PLACED'];
const delayedEvents = everythingElse.pipe(delay(streamerDelayMs));

For odds updates, I only keep the latest pending update per prediction.

For vote activity, I queue events until the corresponding prediction card has been seen.

That way the UI stays causally consistent:

no odds for invisible predictions
no activity for predictions that do not exist yet
no stale creation-time odds for viewers watching with delay

I also enrich delayed PREDICTION_CREATED events with the latest odds right before sending them. That fixes another subtle issue: by the time a delayed viewer sees a new prediction, the original odds may already be outdated.

This was probably the most important architectural shift in the whole feature.

I stopped thinking in terms of "delay everything" and started thinking in terms of "preserve causal order."

LIVE Predictions Were a Special Edge Case

Some predictions are created in the middle of a round and have a very short countdown window.

For example, a bomb-related prediction might only have a few seconds of real voting time.

That creates a strange edge case: by the time the delayed PREDICTION_CREATED event is ready to be delivered, the prediction may already be resolved.

So before sending delayed live predictions, I check their latest status.

If a prediction is already resolved or canceled, I skip sending the stale creation event altogether.

That avoids showing viewers nonsense like a fresh prediction card for something that already ended.

This is the kind of bug that makes a realtime product feel fake even when the backend is technically correct.

The Backend Also Has to Be Delay-Aware

Synchronizing the UI is only half the problem.

The backend also has to accept votes in a way that matches what the viewer actually saw.

So vote validation uses a delay context:

const graceWindowMs = streamerDelayMs + userDelayMs + bufferMs;
const votable = now < closesAt + graceWindowMs;

That context is used for two important checks:

whether a countdown-based prediction is still votable
whether a locked or even recently resolved prediction is still inside a grace window for delayed viewers

This is what makes the system feel fair.

Without it, the UI could say "you still have time" while the API says "too late".

That mismatch kills trust immediately.

This part is easy to miss when talking about stream delay. People usually think about rendering, but fairness is really a validation problem too.

Time Sync Matters More Than It Looks

Another subtle problem: if the client clock drifts, your countdown math is wrong.

So I also added periodic TIME_SYNC events from the server and calculate countdowns against server-adjusted time instead of raw Date.now().

That sounds minor, but once you are combining:

backend event timestamps
streamer delay
viewer delay
countdown windows
grace periods

...even small clock differences become visible in the UI.

So there are really three layers here:

the game event timeline
the delayed delivery timeline
the client's local clock

If those are not reconciled carefully, countdowns and vote windows drift apart.

What the Final Model Looks Like

The current system is basically this:

Server-side

streamer config defines the base delay
API buffers most SSE events by that amount
delayed prediction creation gets refreshed with latest odds
stale live creations are filtered out

Client-side

web reads Twitch player latency via hlsLatencyBroadcaster
extension reads similar latency from Twitch extension context
a median-filtered calculator derives additional viewer delay
events are queued client-side by that extra amount
odds and activity are buffered until their prediction is visible

Validation

vote windows are checked against streamer delay + viewer delay + buffer
countdown rendering uses server-synced time

The result is that two viewers watching the same stream can see the same prediction at different times, and both still get a coherent experience.

That was the real goal.

Not "perfect clocks".

Just a system where predictions feel aligned with what each viewer is actually seeing.

A Few Things I Learned

stream delay is not one number; it is a layered system
measuring delay is easier than preserving event ordering under delay
keeping timestamps pure is much easier than storing delay-adjusted values
you cannot treat all realtime events equally; some need hybrid delivery
fairness lives in backend validation as much as in frontend rendering
Twitch already exposed the latency data I needed - I just found it later than I should have

I still have more technical stories here, especially around dynamic odds under delayed delivery. But the delay problem was the first one that forced me to stop thinking about "realtime" as one timeline shared by everyone.

On Twitch, realtime is per viewer.

And once I accepted that, the architecture got much better.

If you are building anything interactive on top of live streams, I would love to hear how you handled playback delay, event ordering, or fairness windows.