This chapter covers Azure Web PubSub Service, a fully managed real-time messaging service that enables bidirectional communication between clients and servers using WebSocket connections. It is a critical topic for the AZ-204 exam under objective 5.3 'Integrate with messaging and event services,' and typically appears in 5-10% of exam questions. You will learn how Web PubSub works internally, its key components, configuration, and integration patterns, as well as common pitfalls and exam traps.
Jump to a section
Imagine a large conference room where dozens of attendees speak different languages. Each attendee wears an earpiece that can both listen and speak. The room has a central translation server that receives every spoken sentence from any attendee, translates it into all other languages simultaneously, and broadcasts the translated versions back to the appropriate earpieces. However, there's a twist: the server does not store any conversations permanently; it only holds a temporary buffer for active translations. When an attendee speaks, the server instantly distributes the translation to all other attendees who have 'subscribed' to that person's language channel. If an attendee leaves the room (disconnects), the server forgets their subscription and stops sending them translations. New attendees can join at any time and start receiving translations from the moment they subscribe. The server also handles 'group whispers' where a subset of attendees can have a private side conversation without the main room hearing. This mirrors Azure Web PubSub's publish/subscribe model: clients (attendees) connect to a hub (conference room), subscribe to groups (language channels), and the service (translation server) relays messages between clients in real time without storing message history. The earpiece's ability to both send and receive is like a WebSocket connection that supports bidirectional communication. The temporary buffer is analogous to the service's in-memory message delivery, which does not persist messages after delivery.
What is Azure Web PubSub Service?
Azure Web PubSub Service is a fully managed, serverless real-time messaging service that simplifies building applications requiring low-latency, bidirectional communication between a large number of clients and a server. It is built on top of the WebSocket protocol and follows a publish/subscribe (pub/sub) pattern. The service handles the complexity of managing WebSocket connections, scaling, and security, allowing developers to focus on application logic.
Why does it exist?
Traditional real-time communication often requires developers to set up and manage their own WebSocket servers, handle connection scaling, implement authentication, and manage state. This is complex and error-prone. Azure Web PubSub provides a managed alternative that can scale from a few to millions of concurrent connections, supports multiple protocols (WebSocket, server-sent events, long polling), and integrates natively with Azure Functions for serverless architectures. It is designed for scenarios like live chat, real-time dashboards, collaborative editing, and IoT command/control.
How it works internally
At its core, Azure Web PubSub uses a hub-based architecture. A hub is a logical grouping of connections and groups. Clients connect to a hub via a WebSocket URL, and the service maintains the connection state. The service supports two main roles: clients (which can send and receive messages) and servers (which can manage connections and send messages). Communication follows the pub/sub model:
Publishing: A client or server sends a message to a specific hub or group. The service then delivers that message to all subscribers of that hub or group.
Subscribing: Clients subscribe to a hub or group to receive messages. Subscription is implicit when connecting to a hub; explicit groups allow finer-grained control.
Key Components
Hub: A logical container for connections and groups. All connections belong to a hub. Hubs are created automatically when a client connects to a hub endpoint. Example hub name: chat.
Group: A subset of connections within a hub. Groups allow targeted message delivery. For example, a room1 group within a chat hub. Clients can join or leave groups dynamically.
Connection: A WebSocket connection between a client and the service. Each connection has a unique connection ID (generated by the service) and can be authenticated via access tokens.
Permission: Defines what a connection can do. Permissions include: sendToGroup, joinLeaveGroup, listenToGroup. Permissions are assigned via roles in the access token.
Access Token: A JWT token that authenticates a client and specifies the hub, groups, permissions, and expiration. The token is generated by the server or using a negotiation endpoint.
Defaults and Timers
Connection timeout: Default 30 minutes of idle time before the service closes the connection. Configurable via keepAlive interval (client-side ping/pong).
Message size limit: Default 1 MB per message for WebSocket connections. Larger messages are rejected.
Maximum connections per hub: Default 1000 for Free tier, 100,000 for Standard tier (can be increased).
Group membership: No explicit limit on number of groups per connection, but practical limits due to memory.
Token expiration: Default 1 hour if not specified. Max 24 hours.
Configuration and Verification Commands
To create a Web PubSub resource via Azure CLI:
az webpubsub create --name mypubsub --resource-group myrg --location eastus --sku Standard_S1To get the connection string:
az webpubsub key show --name mypubsub --resource-group myrg --query primaryConnectionString -o tsvTo generate a client access token (for testing):
az webpubsub client start --name mypubsub --resource-group myrg --hub chat --user-id user1How it interacts with related technologies
Azure Functions: Web PubSub integrates seamlessly with Azure Functions via bindings. The WebPubSubConnection input binding generates access tokens, and the WebPubSub output binding sends messages to hubs/groups. This enables fully serverless real-time applications.
Azure SignalR Service: Both offer real-time messaging, but Web PubSub is more lightweight and focuses on WebSocket pub/sub, while SignalR supports multiple transport protocols (WebSocket, Server-Sent Events, Long Polling) and provides higher-level abstractions like hubs and methods. Web PubSub is often chosen for simpler scenarios or when direct WebSocket control is needed.
Azure Event Grid: Can be used to trigger serverless functions when clients connect/disconnect or when messages are sent, enabling event-driven architectures.
Azure Logic Apps: Can send messages to Web PubSub via connectors, though less common.
Internal Message Flow
Client establishes a WebSocket connection to the service using an access token.
The service validates the token, assigns a connection ID, and adds the connection to the specified hub.
The client can join groups by sending a special JSON message (e.g., {"type":"joinGroup","group":"room1"}).
When a message is published to a hub or group, the service iterates over all connections in that hub/group and sends the message to each one.
The service does not store messages after delivery. If a client is offline, the message is lost.
The server can also manage connections via REST API or SDK, e.g., to send messages to a specific connection or group.
Protocol Details
Web PubSub uses a simple JSON-based protocol over WebSocket. The client sends messages in a predefined format:
sendToGroup: {"type":"sendToGroup","group":"room1","data":"hello","dataType":"text"}
joinGroup: {"type":"joinGroup","group":"room1"}
leaveGroup: {"type":"leaveGroup","group":"room1"}
Events from the service to the client include:
- message: {"type":"message","from":"group","group":"room1","data":"hello"}
- system: {"type":"system","event":"connected","userId":"user1","connectionId":"xxx"}
Scaling and Performance
Web PubSub automatically scales based on the number of connections. For Standard tier, each unit supports up to 1,000 concurrent connections and 1 MB/s throughput. You can add more units to increase capacity. The service uses a distributed architecture with multiple front-end instances, but developers don't need to manage them. The service guarantees at-least-once delivery within a hub, but due to the lack of persistence, messages may be lost if a client disconnects before receiving. For critical scenarios, combine with a durable message queue.
Create Web PubSub resource
Use Azure portal, CLI, or ARM template to create a Web PubSub service instance. Choose a name, region, and pricing tier (Free or Standard). The resource is created with a default hub named after the resource. The service endpoint is of the form `https://<name>.webpubsub.azure.com`. After creation, retrieve the primary connection string from the 'Keys' blade. This string is used by servers to authenticate and manage the service. The connection string contains the endpoint and an access key.
Generate client access token
The server (or a negotiation function) generates a JWT access token for each client. The token includes the hub name, allowed groups, permissions (e.g., sendToGroup, joinLeaveGroup), and an expiration time. The token is signed with the service's access key. The client receives this token and uses it to connect via WebSocket. The token can be generated server-side using the SDK or via REST API. Example URL: `wss://<name>.webpubsub.azure.com/client/hubs/<hub>?access_token=<token>`.
Client connects to WebSocket
The client opens a WebSocket connection to the service using the URL with the access token. The service validates the token, establishes the connection, and assigns a unique connection ID. The client receives a 'system' event with type 'connected' containing the connection ID and user ID (if provided). The connection is now active and can send/receive messages. The service maintains a heartbeat to detect disconnections.
Client joins a group
To receive targeted messages, the client sends a JSON message to join a group: `{"type":"joinGroup","group":"room1"}`. The service adds the connection to the group's membership list. The client can join multiple groups. Joining a group is necessary to receive messages sent to that group. If a client does not join any group, it only receives messages sent to the entire hub (broadcast).
Publish message to group
A client or server sends a message to a group. For a client, it sends `{"type":"sendToGroup","group":"room1","data":"Hello","dataType":"text"}`. The service receives the message, looks up all connections in that group, and forwards the message to each one. The service does not store the message; delivery is attempted immediately. If a client is disconnected, it misses the message. The server can also send messages via REST API or SDK, e.g., using `SendToGroupAsync`.
Handle disconnection and cleanup
When a client disconnects (gracefully or due to timeout), the service removes the connection from all groups and the hub. The service sends a 'system' event with type 'disconnected' to the server (if event handlers are configured). The server can then perform cleanup, such as notifying other clients. The connection ID becomes invalid. If the client reconnects with a new token, it is treated as a new connection.
Enterprise Scenario 1: Live Chat Application for Customer Support
A company deploys a live chat system on their website using Azure Web PubSub. Customers connect via a browser-based WebSocket client. The server (Azure Function) generates access tokens with limited permissions (only sendToGroup for their specific support agent group). The agent's dashboard subscribes to all customer groups. When a customer sends a message, it is published to their agent's group. The agent replies, and the message is sent back to the customer. The system handles thousands of concurrent chats. Key configuration: Use Standard tier with autoscaling, set token expiration to 1 hour, and configure event handlers to log connections/disconnections. Common misconfiguration: Not setting appropriate permissions, allowing customers to join arbitrary groups, leading to eavesdropping. Solution: Use role-based tokens where customers can only send to their own group.
Enterprise Scenario 2: Real-Time Dashboard for IoT Sensor Data
A manufacturing plant uses Web PubSub to stream sensor data from IoT devices to a monitoring dashboard. Each sensor publishes data to a group named after the machine ID. The dashboard subscribes to all machine groups. The server (running on AKS) processes raw sensor data and publishes aggregated metrics. The system handles 10,000 sensors sending data every second. Performance considerations: Message size is kept under 64 KB to reduce latency. The service is scaled to 10 units to handle throughput. Event handlers are used to trigger alerts when a sensor disconnects. Common issue: Message loss due to disconnection — mitigated by having sensors buffer data locally and retry on reconnect. Another issue: Token expiration causes sensors to disconnect — tokens are set to expire after 24 hours and sensors refresh tokens proactively.
Enterprise Scenario 3: Collaborative Document Editing
A SaaS company builds a collaborative editing feature using Web PubSub. Each document is a group. When a user edits, the change is published to the document group. Other users receive the update and apply it locally. The server handles conflict resolution using operational transforms. The service handles 100,000 concurrent connections across many documents. Configuration: Use Standard tier with private endpoint for security. Event handlers are used to track active editors. Common mistake: Not handling reconnection properly — if a user disconnects temporarily, they miss edits. Solution: Use a persistent store (like Cosmos DB) to log changes and replay on reconnect. Another pitfall: Overloading the service with large messages — limit message size and use delta updates.
What AZ-204 Tests on Web PubSub (Objective 5.3)
The exam focuses on:
Understanding the pub/sub model and how groups work.
Generating and using access tokens (JWT) for authentication.
Integrating with Azure Functions using input/output bindings.
Differentiating Web PubSub from SignalR and Event Grid.
Configuring event handlers for connection lifecycle events.
Scaling and pricing tiers (Free vs Standard).
Security: permissions, roles, and token expiration.
Common Wrong Answers and Traps
Mistaking Web PubSub for SignalR: Many candidates choose SignalR when the scenario requires simple WebSocket pub/sub. SignalR is correct when you need transport fallback (long polling, SSE) or high-level hub method invocation. Web PubSub is for raw WebSocket pub/sub with lower overhead.
Assuming messages are persisted: A common trap is thinking Web PubSub stores messages for offline clients. The exam tests that messages are not persisted — if a client is disconnected, messages are lost. For durability, combine with a queue.
Incorrect token permissions: Candidates may assign overly broad permissions (e.g., allow all clients to send to any group) or forget to include required permissions. The exam may present a scenario where a client cannot send messages because the token lacks sendToGroup permission.
Confusing hub and group: A hub is the top-level container; groups are within a hub. The exam might ask: 'You need to send a message to all connections in a specific room. What should you do?' Answer: Send to a group, not the hub.
Specific Numbers and Terms
Default token expiration: 1 hour (configurable up to 24 hours).
Maximum message size: 1 MB.
Free tier limits: 20 connections, 1 MB/day traffic.
Standard tier unit: 1,000 connections, 1 MB/s throughput.
Protocol: JSON over WebSocket.
Event types: connected, disconnected.
Edge Cases
Token expiration during long-lived connections: The service does not enforce token expiration after connection is established. The token is only validated at connect time. So a client can stay connected beyond token expiration. However, if the client reconnects, they need a new token.
Group membership persistence: Group membership is per connection and is lost on disconnect. There is no persistent group state.
Broadcast to hub: Sending to hub without specifying a group delivers to all connections in that hub.
How to Eliminate Wrong Answers
If the scenario mentions 'multiple transport protocols' or 'automatic fallback', eliminate Web PubSub — choose SignalR.
If the scenario requires 'message persistence' or 'offline support', eliminate Web PubSub — choose a queue or Event Grid.
If the scenario requires 'server-side hub method invocation', choose SignalR.
If the scenario is a simple real-time dashboard or chat with WebSocket only, choose Web PubSub.
Azure Web PubSub is a managed WebSocket pub/sub service for real-time messaging.
Messages are not persisted — delivery is at-most-once; for durability, combine with a queue.
Access tokens are JWT tokens validated at connection time; default expiration is 1 hour.
Maximum message size is 1 MB; messages larger than that are rejected.
Free tier allows up to 20 connections and 1 MB/day; Standard tier scales in units of 1,000 connections.
Groups enable targeted message delivery within a hub; clients join groups via JSON commands.
Event handlers (connected/disconnected) can be configured to trigger serverless functions.
Web PubSub integrates with Azure Functions via input/output bindings for serverless architectures.
These come up on the exam all the time. Here's how to tell them apart.
Azure Web PubSub Service
Lower-level WebSocket pub/sub model.
No automatic transport fallback (WebSocket only).
Simple JSON protocol over WebSocket.
No built-in hub method invocation (server-side RPC).
Ideal for custom real-time protocols or lightweight scenarios.
Azure SignalR Service
Higher-level abstraction with hub methods and client-server RPC.
Automatic transport fallback (WebSocket, SSE, long polling).
Supports multiple serialization formats (JSON, MessagePack, protobuf).
Built-in support for server-side method invocation on clients.
Better for applications needing rich real-time features and broad client compatibility.
Mistake
Azure Web PubSub persists messages for disconnected clients.
Correct
Web PubSub does not persist messages. Messages are delivered only to currently connected clients. If a client disconnects before a message is sent, that message is lost. For persistence, use a durable queue or database.
Mistake
Web PubSub and SignalR are the same service.
Correct
They are different. SignalR provides higher-level abstractions (hubs, methods) and supports multiple transport protocols (WebSocket, SSE, long polling). Web PubSub is a lower-level WebSocket pub/sub service with no built-in method invocation or transport fallback.
Mistake
Access tokens must be refreshed periodically during a connection.
Correct
The access token is only validated at connection time. Once the WebSocket is established, the token can expire without affecting the connection. However, if the client reconnects, a new valid token is required.
Mistake
You can send messages larger than 1 MB by splitting them.
Correct
The service enforces a 1 MB limit per message. Splitting into smaller messages is possible, but the service does not reassemble them. The application must handle fragmentation.
Mistake
Web PubSub supports server-sent events (SSE) natively.
Correct
Web PubSub primarily uses WebSocket. It does not natively support SSE or long polling. For SSE, use SignalR. Web PubSub is focused on WebSocket pub/sub.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You generate a JWT access token server-side using the service's connection string and SDK. The token specifies the hub, allowed groups, permissions (e.g., sendToGroup, joinLeaveGroup), and expiration. Example using C# SDK: `var service = new WebPubSubServiceClient(connectionString, hubName); var token = await service.GetClientAccessUriAsync(roles: new[] { "webpubsub.joinLeaveGroup", "webpubsub.sendToGroup" });`. The client uses the returned URI to connect via WebSocket.
Yes. Azure Functions provides input and output bindings for Web PubSub. The `WebPubSubConnection` input binding generates access tokens, and the `WebPubSub` output binding sends messages to hubs/groups. This enables fully serverless real-time applications. You also configure event handlers (connected/disconnected) to trigger functions.
Nothing — the token is only validated at connection time. The existing WebSocket connection remains active. However, if the client disconnects and tries to reconnect with an expired token, the connection will be rejected. For long-lived connections, you can generate tokens with longer expiration (up to 24 hours) or implement token refresh logic.
Use the server SDK or REST API. For example, in C#: `await service.SendToGroupAsync("room1", "Hello", WebPubSubDataType.Text);`. You can also send to a specific connection using `SendToConnectionAsync`. The server must be authenticated using the connection string.
Sending to a hub delivers the message to all connections in that hub. Sending to a group delivers only to connections that have joined that specific group. Groups allow finer-grained targeting. If you send to a hub, all connections receive it, regardless of group membership.
Yes, the service supports Azure AD authentication for management operations (e.g., creating resources) and for data plane operations (e.g., sending messages) using managed identities. However, client connections still use access tokens (JWT) for authentication. You can configure the service to accept AAD tokens for client connections, but it's more common to use access tokens.
Use Azure Monitor metrics and logs. Key metrics include: Connection Count, Message Count, Inbound/Outbound Traffic. You can also enable diagnostic settings to send logs to Log Analytics, Storage, or Event Hubs. Event handlers can log connection/disconnection events.
You've just covered Azure Web PubSub Service — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?