5 exercises — 5 exercises practising CRDT, operational transforms, SFU vs. MCU architecture, presence indicators, and real-time collaboration vocabulary.
0 / 14 completed
1 / 14
A team is choosing between CRDT and Operational Transform (OT) for their collaborative document editor. Which description correctly compares the two approaches?
The core trade-off: OT is server-centric (simpler algorithm but requires always-on server coordination); CRDT is distributed (complex data structure but no server needed for consistency).
OT (used in Google Wave, ShareDB): when two clients make concurrent edits, a server transforms operation B to account for operation A having already been applied, then sends the transformed B to all clients. This requires the server to see all operations and handle the transformation logic. Works well for a single-master architecture but is hard to implement correctly for multi-master. CRDT (used in Yjs, Automerge): each operation is a self-describing structure that can be merged with any other operation in any order and always produces the same result (commutativity and idempotency). No server needed for conflict resolution. Well-suited for P2P (WebRTC data channels), offline-first apps, and multi-region replication.
Key vocabulary: • CRDT (Conflict-free Replicated Data Type) — data structure where concurrent operations always merge correctly without coordination • OT (Operational Transform) — algorithm transforming operations to account for concurrent edits; requires server • commutativity (CRDT) — the property that CRDT operations produce the same result regardless of application order
2 / 14
A developer explains: "We use a Yjs CRDT shared document over WebRTC data channels for our collaborative whiteboard." What is a WebRTC data channel and how does it differ from WebRTC media?
Data channels enable arbitrary P2P data transfer with the same NAT traversal that WebRTC uses for media — no separate server or connection needed.
RTCDataChannel properties: ordered (default: true) — like TCP, messages arrive in order; unreliable (maxRetransmits: 0) — like UDP, best-effort delivery for low-latency gaming or position updates; maxPacketLifeTime — drop old messages if not delivered within N milliseconds. CRDT sync via data channels: Yjs encodes document updates as compact binary diffs. When user A types, the Yjs update is encoded and sent over the data channel to all peers. Each peer applies the CRDT operation locally — guaranteed to converge to the same document state regardless of order. Offline edits accumulate and sync automatically when the data channel reconnects.
Key vocabulary: • RTCDataChannel — WebRTC API for bidirectional arbitrary data transfer; uses SCTP over DTLS • SCTP (Stream Control Transmission Protocol) — the transport protocol under data channels; supports ordered/unordered, reliable/unreliable delivery modes • Yjs — a CRDT framework for building collaborative applications; supports text, maps, arrays, and custom types
3 / 14
A platform team is designing a video conferencing system for 50 participants. They debate SFU vs. MCU architecture. Which comparison is correct?
SFU is the modern default for video conferencing — lower server cost, better quality — but MCU has value for low-bandwidth endpoints like mobile users on 3G.
SFU with 50 participants: each participant receives 49 streams. The SFU server just forwards packets — CPU is low. But the client needs enough bandwidth for 49 streams (typically reduced via simulcast to 200kbps × 49 = ~10Mbps for grid view — impractical). Real implementations use "active speaker detection": the SFU only forwards the streams of the last few active speakers (2-4) to each participant. This reduces client bandwidth to 2-4 × 800kbps = manageable. MCU with 50 participants: the server decodes all 50 streams and composites them into a grid video at real-time. Server CPU: enormous. But each client receives one 2Mbps stream. MCU shines for: dial-in phone participants (one audio stream), legacy endpoints, and very low bandwidth mobile users.
Key vocabulary: • SFU (Selective Forwarding Unit) — media server forwarding streams without decoding; low CPU; each receiver downloads N streams • MCU (Multipoint Control Unit) — mixes all streams server-side; high CPU transcoding; each receiver downloads 1 stream • active speaker detection — technique reducing SFU bandwidth by forwarding only the speaking participants' streams
4 / 14
A product manager asks: "How does our app know when a user is actively typing vs. just present?" The developer mentions presence and awareness. What do these terms mean in real-time collaboration context?
Presence = is this user connected; Awareness = what are they doing. Rich awareness (cursor sharing, selection highlighting) is what makes collaborative editing feel live.
Yjs Awareness protocol example: each user broadcasts a state object: { user: { name: 'Alex', color: '#f00' }, cursor: { index: 42, length: 0 }, isTyping: true }. All connected peers receive this state update and can render Alex's cursor at position 42 with a red colour and a "typing" indicator. Awareness state is intentionally ephemeral — it is not stored in the CRDT document; it is re-broadcast every time a user reconnects. Heartbeat interval (typically 30 seconds) keeps the presence list accurate: if a user's heartbeat stops, they are removed from the awareness state after a timeout.
Key vocabulary: • presence — user online/offline status in a real-time session • awareness — per-user ephemeral state (cursor, selection, typing) broadcast to all collaborators in real time • Yjs Awareness protocol — lightweight CRDT-adjacent protocol for broadcasting presence/cursor state without persistence
5 / 14
A developer describes implementing a WebSocket reconnection strategy for a real-time collaborative app. What does a robust reconnection strategy involve?
Exponential backoff + jitter is the standard pattern — without jitter, thousands of clients reconnect simultaneously after a server restart, causing a "thundering herd" that crashes the server again.
Implementation: let delay = Math.min(baseDelay * 2**attempt, maxDelay); delay += Math.random() * jitterMs. On reconnect, the client must re-sync missed state: for CRDT apps, request all updates since last known clock; for event-sourced apps, fetch events since last sequence number; for snapshot-based apps, request the current state. The UI should clearly indicate the reconnection status: "Connection lost — reconnecting in 4 seconds" prevents users from thinking the app has crashed and prevents rage-clicking that generates duplicate data. WebSocket's onclose event fires with a reason code — check code 1001 (going away) vs. 1006 (abnormal closure) to distinguish intentional server shutdown from network failure.
Key vocabulary: • exponential backoff — doubling retry delay with each failed attempt; prevents overwhelming a recovering server • jitter — random variation added to backoff delay; prevents thundering herd when many clients reconnect simultaneously • thundering herd — all disconnected clients reconnecting at the same moment after a server restarts; can crash the server again
6 / 14
Sarah from the design team asks: 'When we're using WebRTC for real-time drawing collaboration, what does it mean to say we have 'low latency'?'
Latency in WebRTC is fundamentally about delay – specifically, the time it takes for data to travel between participants. Low latency is crucial for real-time collaboration because it minimizes perceptible delays when drawing or interacting with the shared canvas. Option A describes bandwidth, which is related but not the core definition of latency.
7 / 14
Mark, a junior developer, writes in a Slack channel: 'We're using WebRTC signaling servers to negotiate connections between users. What's the primary function of these servers?'
WebRTC signaling servers aren't involved in data transmission or scaling. Their core role is to orchestrate the *handshake* – the initial negotiation phase where users exchange information necessary for establishing a WebRTC connection. This includes SDP (Session Description Protocol) offers and answers, which define the capabilities of each peer.
8 / 14
John from the backend team is explaining the architecture to a new developer: 'We're using WebRTC for low-latency video conferencing. The server-side component, the SFU, handles all the media processing and synchronization.' What is the primary role of an SFU (Selective Forwarding Unit) in this scenario?
An SFU (Selective Forwarding Unit) is crucial in low-latency video conferencing because it efficiently distributes the incoming media streams. Unlike an MCU (Multipoint Control Unit), which combines all streams into one, the SFU forwards only the necessary data to each participant, minimizing latency and network bandwidth usage. This contrasts with authentication or encryption – those are separate security components.
9 / 14
Maria, a senior developer, is discussing real-time collaboration features in a Slack channel: 'We're using WebRTC signaling servers to establish connections between users. The signal server handles the negotiation of media capabilities and SDP offers/answers.' What does an SDP (Session Description Protocol) offer/answer process typically involve?
The SDP offer/answer process is the core of WebRTC signaling. Clients exchange SDP messages describing their media capabilities (like supported codecs) – this allows them to find a common set of parameters for establishing a connection. This negotiation determines what each client can actually send and receive in real-time.
10 / 14
David is reviewing a PR description for a new feature that utilizes WebRTC for collaborative editing: 'We're leveraging persistent connections to ensure minimal data loss and rapid updates during concurrent edits.' What is the primary benefit of establishing *persistent* connections in this context?
Persistent connections – typically using WebSockets or similar technologies – are fundamental to real-time collaboration. They maintain a continuous link between clients and the server, enabling immediate transmission of updates whenever changes occur. This contrasts with connection establishment/tear down which introduces latency.
11 / 14
Tom writes in a code review comment: 'To handle disconnections gracefully, we implemented a WebSocket reconnection strategy with exponential backoff.' What is the primary purpose of an *exponential backoff* strategy in this context?
Exponential backoff is a common technique for dealing with intermittent network issues. After a WebSocket connection fails, the strategy increases the delay between reconnection attempts (e.g., 1 second, 2 seconds, 4 seconds...). This prevents overwhelming the server if there are multiple failed connections and gives the underlying network time to recover.
12 / 14
Sarah is testing a new feature for collaborative drawing using WebRTC. She's noticing that changes aren't appearing immediately on everyone's screen. What is the most likely cause of this delay?
{ "title": "Real-Time Collaboration" }
WebRTC data channels have inherent latency due to network transmission times. While a server overload *could* contribute, the primary cause of delay in real-time collaborative applications is typically network latency – the time it takes for messages to travel between devices. Options 1 and 4 are less likely as they involve direct issues with the system.
13 / 14
Mark is debugging a collaborative document editor built using WebRTC and Yjs. He notices that changes made by one user are sometimes lost or appear out of order in another user's view. Which aspect of the system configuration is MOST likely to be causing this issue?
{ "title": "Synchronization Issues" }
Centralized servers, while common in collaborative applications, introduce a single point of failure and can create bottlenecks. Decentralized CRDTs like Yjs rely on local conflict resolution to ensure data consistency across users without the need for constant server intervention – this is where problems arise if not implemented correctly.
14 / 14
Maria is explaining to a new developer how the signaling server works during WebRTC connection establishment. Which statement best describes its primary function?
{ "title": "Signaling Server Role" }
Signaling servers are responsible for *negotiating* the connection parameters needed for WebRTC peers to establish a peer-to-peer connection. This includes exchanging information like IP addresses, ports, media capabilities, and security settings – they do not transmit the actual audio or video data.
What does this WebRTC & Real-Time Language exercise cover?
This exercise, "Real-Time Collaboration Technologies — Vocabulary", tests your understanding of webrtc & real-time language vocabulary and phrasing through 14 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 14 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this WebRTC & Real-Time Language exercise for?
It's designed for IT professionals and learners who want to sound natural discussing webrtc & real-time language topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more WebRTC & Real-Time Language exercises?
Browse the full WebRTC & Real-Time Language exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.