This chapter covers Azure Fluid Relay, a managed service for real-time collaborative applications. You will learn how it enables low-latency, conflict-free data synchronization across clients using Fluid Framework. For the AZ-204 exam, this topic appears in Domain 5 (Integrate), Objective 5.3, and typically accounts for 5-10% of questions. Mastering Fluid Relay is essential for building collaborative apps like co-authoring, whiteboarding, and multiplayer games on Azure.
Jump to a section
Imagine a team collaborating on a large whiteboard in a conference room. Each person has a marker, and they can write, erase, and draw simultaneously. The whiteboard is actually a digital surface that broadcasts every stroke to all participants in real time. When you draw a line, your marker sends a message to a central server that owns the authoritative copy of the whiteboard. That server immediately forwards your stroke to everyone else’s local view. If two people draw at the exact same spot, the server uses a conflict resolution algorithm—like last-writer-wins or merge based on operational transforms—to decide the final state. This server is not just a relay; it also stores the entire history of strokes so that if someone joins late, they can replay every action from the beginning and see the whiteboard as it evolved. The server also manages permissions: only invited participants can write, and the host can revoke access at any time. In Azure Fluid Relay, the whiteboard is a distributed data structure (DDS), the strokes are operations (ops), and the server is the Fluid Relay service that ensures all clients converge to the same state, even under network delays or temporary disconnections.
What is Azure Fluid Relay?
Azure Fluid Relay is a fully managed cloud service that hosts the Fluid Framework server component. Fluid Framework is an open-source platform for building real-time, collaborative experiences. It provides distributed data structures (DDS) that automatically synchronize state across multiple clients. The Fluid Relay service acts as the central hub: it receives operations (ops) from clients, orders them, broadcasts them to other clients, and persists the op log. It also handles user authentication and authorization via Azure AD.
Why It Exists
Traditional real-time collaboration often uses WebSockets with custom conflict resolution, which is complex and error-prone. Fluid Framework abstracts away the complexity by providing a set of built-in DDS like SharedMap, SharedString, and SharedCounter. These data structures use Operational Transformation (OT) or Conflict-Free Replicated Data Types (CRDTs) to ensure eventual consistency. Azure Fluid Relay offloads the server-side logic, scaling, and security to Azure, so developers focus on client code.
How It Works Internally
Each Fluid client creates a container, which is a collection of DDS. The container is hosted on the Fluid Relay service. When a client modifies a DDS (e.g., adds an item to a SharedMap), it generates an operation (op) that describes the change. The op is sent to the Fluid Relay via a WebSocket. The relay assigns a global sequence number to the op, appends it to the op log, and broadcasts it to all other connected clients. Clients apply the op to their local copy of the DDS, ensuring everyone converges to the same state. If a client disconnects and reconnects, it fetches missed ops from the relay.
Key Components
Fluid Client: JavaScript/Typescript library that runs in the browser or Node.js. It creates containers and DDS.
Fluid Container: A unit of collaboration. Contains one or more DDS. Each container has a unique ID.
Distributed Data Structures (DDS): SharedMap (key-value), SharedString (rich text), SharedCounter (integer), SharedObject (custom).
Fluid Relay Service: Azure-managed endpoint that accepts ops, orders them, and broadcasts. Has a REST API for container creation and WebSocket for real-time ops.
Azure AD: Used for authentication. Clients must obtain an access token with the scope fluidrelay.containers.read or fluidrelay.containers.readwrite.
Op Log: Append-only log of all operations. Used for persistence and catch-up.
Summarizer: A client that periodically creates a summary (snapshot) of the container state to reduce replay time.
Defaults and Timers
Op TTL: Ops are stored for 30 days by default. After that, they are purged.
Summary Interval: A summary is generated every 5 seconds of inactivity or after 100 ops, whichever comes first.
WebSocket Keepalive: 30-second ping interval.
Token Expiry: Azure AD tokens for Fluid Relay expire after 1 hour by default. Clients must refresh tokens before expiry.
Container Creation: Requires a containerId (GUID). The first client creates it; subsequent clients join.
Configuration and Verification
To create a Fluid Relay resource:
az fluid-relay server create --resource-group myGroup --name myFluidRelay --location westus2To get connection strings:
az fluid-relay server show --resource-group myGroup --name myFluidRelay --query "fluidRelayEndpoints"In client code, connect using:
import { AzureClient } from '@fluidframework/azure-client';
const client = new AzureClient({
connection: {
type: 'remote',
tenantId: 'my-tenant-id',
tokenProvider: new InsecureTokenProvider('my-key', { id: 'user1' }),
endpoint: 'https://myFluidRelay.westus2.fluidrelay.azure.com',
}
});
const container = await client.createContainer(containerSchema);Interaction with Related Technologies
Azure AD: Required for token-based authentication. Use @fluidframework/azure-service-client with AzureTokenProvider.
Azure Functions: Can be used to generate tokens on demand, avoiding client-side secrets.
Azure Cosmos DB: Not directly used by Fluid Relay; Fluid stores ops in its own storage. However, you can persist container metadata in Cosmos DB for your app.
Azure SignalR Service: SignalR is for real-time messaging; Fluid Relay uses WebSockets natively but can integrate with SignalR for custom signaling.
Azure Blob Storage: Used internally by Fluid Relay for op log persistence. Not directly accessible by users.
Operational Transformation vs CRDT
Fluid Framework uses a hybrid approach. For SharedString, it uses OT with a custom algorithm. For other DDS, it uses CRDTs. The exam does not require deep knowledge of the algorithm, but you should know that Fluid ensures eventual consistency without conflicts.
Security
Authentication: Azure AD tokens with scoped permissions.
Authorization: Container-level read/write permissions. A client can only join a container if it has a valid token with appropriate scope.
Data Encryption: At rest (Azure Storage encryption) and in transit (TLS 1.2+).
Network Security: Fluid Relay can be integrated with Azure Private Link for private endpoints.
Limits
Container Size: Up to 1 GB of op log per container.
Ops per second: Up to 100 ops per second per container.
Concurrent Clients: Up to 100 clients per container.
Region: Available in select Azure regions (West US, West Europe, etc.).
Code Example: Collaborative Counter
const container = await client.getContainer(containerId, containerSchema);
const counter = container.initialObjects.counter;
counter.on('valueChanged', (delta) => {
document.getElementById('counter').innerText = counter.value;
});
button.onclick = () => counter.increment(1);This example shows how a SharedCounter DDS synchronizes across clients.
Create Fluid Relay Resource
In Azure Portal or CLI, create a Fluid Relay resource. This provisions a managed endpoint with a tenant ID and primary key. The resource is region-specific. Use `az fluid-relay server create` with parameters like resource group, name, and location. The output includes the Fluid Relay endpoints (e.g., `https://<name>.<region>.fluidrelay.azure.com`) and the tenant ID. This endpoint is where clients connect.
Configure Authentication
Register an Azure AD application for your client app. Grant it API permissions for the Fluid Relay resource (e.g., `fluidrelay.containers.readwrite`). Generate an access token using the client credentials flow or on-behalf-of flow. The token must include the `aud` claim set to the Fluid Relay endpoint. Use `@fluidframework/azure-client` with `AzureTokenProvider` to obtain tokens. For development, you can use `InsecureTokenProvider` with the primary key.
Create a Container
From the client, call `client.createContainer(containerSchema)`. The schema defines the DDS objects (e.g., SharedMap, SharedString). The Fluid Relay service assigns a unique container ID and returns it. The container is now persistent. The first client is the creator; subsequent clients join using the same container ID. The container is stored in the Fluid Relay's op log.
Join a Container
Other clients call `client.getContainer(containerId, containerSchema)` with the same container ID. They must have a valid token with read or readwrite permission. The client fetches the container's initial state from the Fluid Relay (via summary or op replay). It then opens a WebSocket to receive live ops. The client's local DDS are initialized with the current state.
Send Operations
When a user modifies a DDS (e.g., updates a SharedMap key), the Fluid client generates an op. The op is a JSON object describing the change (e.g., `{type: 'set', key: 'color', value: 'red'}`). It is sent over the WebSocket to the Fluid Relay. The relay assigns a sequence number, appends it to the op log, and broadcasts it to all other connected clients. Clients apply the op to their local DDS, triggering `valueChanged` events.
Handle Disconnection and Reconnection
If a client loses WebSocket connection, it attempts to reconnect with exponential backoff. Upon reconnection, it sends a request for missed ops (based on last known sequence number). The Fluid Relay returns any ops after that sequence. The client replays them to catch up. The client also fetches the latest summary if the gap is large. This ensures the client is fully synchronized.
Enterprise Scenario 1: Collaborative Document Editing
A SaaS company builds a real-time document editor (like Google Docs) using Fluid Framework. They use SharedString for the document content and SharedMap for comments. The Fluid Relay service is deployed in West US. Users across the globe experience latency; to mitigate, the company uses Azure Front Door to route to the nearest region. They also implement Azure AD B2C for customer authentication. The container ID is stored in a database per document. Performance is monitored via Azure Monitor metrics: op latency, connection count, and throughput. Misconfiguration: If the token scope is set to read instead of readwrite, users cannot edit. Another issue: if the container schema changes after creation, old clients may fail to join unless backward compatibility is handled.
Scenario 2: Real-Time Whiteboard for Education
An EdTech startup builds a virtual whiteboard for online classes. They use SharedMap for shapes and SharedString for text. The Fluid Relay is deployed in two regions for redundancy. They use Private Link to keep traffic within Azure. The summarizer runs on a serverless function to reduce client load. Scalability: They monitor concurrent users per container; if >100, they create a new container per session. Common failure: When the primary key is rotated, clients using InsecureTokenProvider break until updated. Solution: Use Azure AD tokens that can be refreshed.
Scenario 3: Multiplayer Game State Sync
A game studio uses Fluid Relay to synchronize game state (e.g., player positions, scores) in a turn-based strategy game. They use SharedMap for player data and SharedCounter for scores. The op log is used for replay and debugging. They limit ops per second to avoid throttling. Performance: They use Azure CDN for static assets and Fluid Relay for real-time state. Misconfiguration: If the container is not created before clients join, they get a 404 error. Also, if the token expires mid-session, the WebSocket disconnects; they must implement token refresh logic.
What AZ-204 Tests
Objective 5.3: 'Integrate Azure Fluid Relay for real-time collaboration.' The exam focuses on:
Understanding the Fluid Framework components: containers, DDS, ops, summarizer.
Authentication: Azure AD tokens with correct scopes (fluidrelay.containers.readwrite).
Connection: Using AzureClient with remote connection type.
Differences between Fluid Relay and other real-time services (SignalR).
Limits: 100 ops/sec, 100 clients/container, 30-day op retention.
Common Wrong Answers
'Use Azure SignalR Service instead of Fluid Relay for collaborative state sync.' Wrong: SignalR is for real-time messaging, not for distributed data structures with conflict resolution. Fluid Relay is purpose-built for collaboration.
'Fluid Relay uses Azure Cosmos DB to store ops.' Wrong: Fluid Relay uses Azure Blob Storage internally, not Cosmos DB.
'The Fluid client must directly connect to the Azure AD endpoint.' Wrong: The client connects to the Fluid Relay endpoint; Azure AD tokens are obtained separately.
'Fluid Relay supports up to 1000 clients per container.' Wrong: The limit is 100.
Specific Numbers and Terms
Container ID: GUID.
Op retention: 30 days.
Summary interval: 5 seconds or 100 ops.
Max ops/sec: 100.
Max clients/container: 100.
Token scope: fluidrelay.containers.readwrite.
Client library: @fluidframework/azure-client.
DDS examples: SharedMap, SharedString, SharedCounter.
Edge Cases
Late-joining client: Must replay ops from the beginning or use a summary. The summarizer reduces catch-up time.
Token expiry: Client must refresh token before expiry; otherwise WebSocket disconnects.
Container schema mismatch: If schema changes, old clients may fail to deserialize DDS. Use versioning.
Region unavailability: Fluid Relay is not available in all regions; check regional availability.
How to Eliminate Wrong Answers
If the question mentions 'real-time state sync without conflict resolution', Fluid Relay is correct, not SignalR.
If the answer mentions 'Cosmos DB' or 'SQL Database' for storage, it is wrong.
If the answer suggests using @microsoft/signalr for the client, it is wrong; use @fluidframework/azure-client.
If the answer says 'no authentication required', it is wrong; Azure AD is mandatory.
Azure Fluid Relay is a managed service for real-time collaboration using Fluid Framework.
It uses distributed data structures (DDS) like SharedMap, SharedString, and SharedCounter.
Authentication requires Azure AD tokens with scope fluidrelay.containers.readwrite.
The client library is @fluidframework/azure-client.
Ops are persisted for 30 days; summaries are generated every 5 seconds or 100 ops.
Maximum 100 ops per second and 100 concurrent clients per container.
Fluid Relay is different from SignalR; it's for state sync, not just messaging.
Container IDs are GUIDs; containers are created by the first client and joined by others.
These come up on the exam all the time. Here's how to tell them apart.
Azure Fluid Relay
Purpose-built for collaborative state synchronization using distributed data structures.
Provides built-in conflict resolution via OT/CRDT.
Client uses Fluid Framework libraries (@fluidframework/azure-client).
Persists op log for history and catch-up.
Supports up to 100 clients per container.
Azure SignalR Service
General-purpose real-time messaging (e.g., chat, notifications, live updates).
No built-in data structures or conflict resolution; you implement custom logic.
Client uses SignalR SDK (@microsoft/signalr).
Does not persist messages by default; you must implement storage.
Supports up to 100,000 concurrent connections per hub (scalable).
Mistake
Azure Fluid Relay is just another WebSocket service like Azure SignalR.
Correct
Fluid Relay is built on Fluid Framework, which provides distributed data structures with automatic conflict resolution. SignalR is a generic real-time messaging service; Fluid Relay is specialized for collaborative state synchronization.
Mistake
Fluid Relay stores data in Azure Cosmos DB.
Correct
Fluid Relay uses Azure Blob Storage for persisting the op log and summaries. Cosmos DB is not used internally.
Mistake
You can use Fluid Relay without any authentication.
Correct
Authentication via Azure AD is mandatory. Each request must include a valid access token with appropriate scopes. In development, you can use InsecureTokenProvider with the primary key, but production requires Azure AD.
Mistake
Fluid Relay supports unlimited concurrent clients per container.
Correct
The limit is 100 concurrent clients per container. Beyond that, you need to create additional containers or use a different architecture.
Mistake
The Fluid client connects directly to Azure AD to get tokens.
Correct
The Fluid client connects to the Fluid Relay endpoint. Tokens are obtained separately from Azure AD and passed to the client via a token provider.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You must use Azure AD tokens. Register an application in Azure AD, grant it API permissions for the Fluid Relay resource (e.g., fluidrelay.containers.readwrite). Use a token provider like AzureTokenProvider from @fluidframework/azure-service-client to obtain tokens. In development, you can use InsecureTokenProvider with the primary key, but this is not recommended for production.
Fluid Relay is designed for real-time collaboration with automatic state synchronization and conflict resolution using distributed data structures. SignalR is a generic real-time messaging service that requires you to implement your own data structures and conflict resolution. Use Fluid Relay for collaborative apps like co-authoring; use SignalR for chat or notifications.
The client attempts to reconnect with exponential backoff. Upon reconnection, it requests missed ops from the Fluid Relay based on the last known sequence number. The relay sends all ops after that sequence, and the client replays them. If the gap is large, the client fetches the latest summary to catch up quickly.
Yes, you can use Azure Functions to generate tokens on demand. The function authenticates with Azure AD and returns a token to the client. This avoids storing secrets on the client. You can also use Functions to create containers or manage metadata.
Per container: up to 100 concurrent clients, 100 ops per second, 1 GB op log size. Ops are retained for 30 days. The service is available in select Azure regions. If you exceed these limits, you may experience throttling or errors.
From the client, call client.createContainer(containerSchema) with a schema defining the DDS. The Fluid Relay assigns a container ID and returns it. The container is now persistent. Subsequent clients join using client.getContainer(containerId, containerSchema).
A summarizer is a client that periodically creates a summary (snapshot) of the container state. This summary is stored in the Fluid Relay and used by late-joining clients to avoid replaying the entire op log. The default interval is every 5 seconds of inactivity or after 100 ops.
You've just covered Azure Fluid Relay for Real-Time Collaboration — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?