Synkly’s promise is simple to state and hard to deliver: everyone in a room sees the same frame at the same moment, whether they are on fiber in Bangalore or patchy hotel wifi in Berlin. This post walks through how the sync engine actually works — the clock model, the drift-correction strategy, what happens when someone joins late or loses their connection entirely, and why the same infrastructure powers all eight of our multiplayer games.
Why watch-party sync is a hard problem
Two people pressing play "at the same time" are never actually at the same time. Network latency differs per viewer and per second. Browsers buffer unpredictably. A phone throttles its media pipeline when the battery dips. Left alone, two players that started in perfect sync drift apart by seconds within minutes — and nothing kills a shared movie night faster than hearing your friend react to a scene you have not seen yet.
Naive fixes make it worse. Syncing by having clients broadcast their positions to each other turns every room into a negotiation with N² chatter. Hard-seeking every viewer to the average position produces the jarring skip-stutter that plagues most watch-party tools. And trusting client clocks at all imports every device’s clock skew into your sync math.
A single source of truth for playback state
Every Synkly room has one authoritative playback clock that lives on the server. It is a tiny state machine: media reference, a play/pause flag, a timecode anchor and the server timestamp of the last change. Clients never negotiate with each other — each one independently reconciles against that clock on a fixed interval.
- Server-authoritative clock — one writer, many readers, zero peer-to-peer disagreement
- Client-side smoothing — reconciliation runs continuously, not just on play/pause events
- Latency-compensated timestamps — each client offsets the clock by its own measured round-trip time
- Presence, chat, reactions and game state ride the same low-latency WebSocket channel as playback
The state machine being tiny is a feature. Because a room’s entire playback truth fits in a few dozen bytes, it is cheap to broadcast, trivial to persist, and instant to hand to a newcomer — which pays off directly in the next two sections.
Correcting drift without jarring seeks
The interesting engineering is in how a client gets back in sync once it drifts. Seeking is the sledgehammer — it drops frames, triggers rebuffering, and is exactly the stutter viewers hate. So Synkly treats seeks as a last resort and playback-rate nudging as the default.
Small drift gets a small nudge: the player runs imperceptibly faster or slower — well inside the range where neither video nor audio pitch is noticeable — until it converges. Bigger drift gets a proportionally bigger nudge, capped to stay invisible. Only when drift crosses the threshold where nudging would take too long does the client hard-seek, and it does so once, to a latency-compensated target, rather than oscillating.
Adaptive correction means a healthy connection is never touched, a briefly-hiccuping one glides back without the viewer noticing, and a genuinely broken one recovers in a single decisive step. The correction curve was tuned against real living-room conditions — laptop speakers, lip-sync sensitivity, the human tolerance for pitch — not against a lab network.
Late joiners and the cold-start problem
Someone always joins twenty minutes in. A late joiner receives the room’s clock state in the connection handshake, computes the current authoritative position locally, and starts buffering directly at that timecode — not at zero. By the time the player is ready, it opens already in sync, and the standard reconcile loop takes over from the first frame. No one else’s playback is touched; the room never pauses to absorb a newcomer.
When the network fails entirely
Sync engineering is mostly failure engineering. When a client loses its socket, it keeps playing locally — freezing a room because one phone entered an elevator would punish everyone for one connection. On reconnect, the client fetches the clock, measures fresh round-trip latency, and rejoins through the same late-joiner path: reconcile once, decisively, then resume smoothing.
The server side is deliberately boring: room state is small enough to replicate cheaply, so a node failure moves rooms to a healthy node with the clock intact. Viewers experience at worst a brief hiccup — never a room reset, never a "host has left" dead end, because there is no privileged host connection to lose.
One channel for video, chat and eight games
The same clock-and-reconcile pattern generalizes past video. Sketcha strokes, Ludo dice rolls, Sea Battle shots and Laser Chess moves are all state transitions against a server-authoritative source of truth, broadcast on the same channel as playback and presence. Building one excellent real-time layer and reusing it eight times is why a two-product studio can ship eight multiplayer games with live leaderboards at all.
Sharing the channel has a subtler benefit: ordering. A chat reaction to a goal, the pause that follows it, and the game invite someone sends in the excitement all arrive in the same sequence for every viewer, because they travel the same pipe. Games add one requirement video does not have — fairness. A dice roll or a drawn card is generated on the server and broadcast as a result, never computed on a client, so identical state on every screen is guaranteed rather than hoped for.
How we measure "in sync"
We track drift as the gap between each client’s actual playback position and the authoritative clock, sampled continuously and reported as percentiles per room. The target is under 60ms end to end — roughly two frames at 30fps, tighter than the threshold where lip-sync errors become perceptible — and the vast majority of sessions hold it. When a room degrades, the telemetry says which viewer, which network, and which correction strategy engaged, which turns "it felt laggy" into a fixable bug report.
Percentiles matter more than averages here. A room where nine viewers are perfect and one is four seconds behind has a great average and a ruined movie night. We alarm on the worst viewer in the room, because that is the experience the group actually has.
What this buys you
None of this machinery is visible in the product, which is the point. You press play, everyone sees the same frame, the dice land the same way on every screen, and distance stops mattering for a couple of hours. That is the entire feature. The engineering exists so nobody has to think about it.