This chapter covers Azure Notification Hubs, a scalable push notification engine that enables sending millions of notifications to mobile and desktop applications across multiple platforms. For the AZ-204 exam, this topic falls under Domain 5 (Integrate), Objective 5.1 (Implement push notifications). Expect approximately 5-8% of exam questions to touch on Notification Hubs, focusing on architecture, installation, registration, and template usage. Mastering this topic is critical for passing the exam.
Jump to a section
Think of Azure Notification Hubs as a radio broadcast station. The station (Notification Hub) has a single powerful transmitter that can send messages to many different types of receivers (devices). Each receiver type (e.g., iOS, Android, Windows) uses a different frequency or protocol (APNs, FCM, WNS). The station doesn't need to know every listener's exact location; instead, it broadcasts on a specific frequency, and listeners tuned to that frequency receive the message. In this analogy, when a radio station wants to send a traffic alert, it doesn't call each listener individually. It broadcasts once, and all radios tuned in receive it simultaneously. Similarly, developers send a single push notification to the Notification Hub, which then fans out to millions of devices across different platforms. The hub handles the complexity of translating the message into platform-specific formats (APNs for iOS, FCM for Android, WNS for Windows) and delivering it efficiently. Just as a radio station can target specific regions by using different transmitter powers or frequencies, a Notification Hub can target specific audiences using tags and templates, ensuring that only relevant devices receive the message. This abstraction saves developers from having to manage multiple connections to each push notification service.
What is Azure Notification Hubs?
Azure Notification Hubs is a fully managed push notification service that allows you to send high-volume, low-latency notifications to any platform (iOS, Android, Windows, Kindle, Baidu) from any backend (cloud or on-premises). It eliminates the complexity of managing direct connections to Platform Notification Systems (PNS) like Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM), and Windows Notification Service (WNS).
Why Notification Hubs exist
Before Notification Hubs, developers had to write and maintain separate code for each PNS. Each PNS has different APIs, authentication methods, and payload formats. Scaling to millions of devices required managing multiple connections, handling retries, and dealing with platform-specific throttling. Notification Hubs abstracts these differences, providing a single API endpoint for sending notifications. It also offers features like tag-based routing, templates for localization, and telemetry.
How it works internally
Installation Registration: Each device app, upon startup, obtains a unique handle (device token) from the respective PNS. The app then sends this handle to the Notification Hub, along with any tags (e.g., "user:123", "news:sports"). The hub stores this registration in its database, associating the handle with the tags and the platform type.
Send Notification: A backend application sends a notification message to the hub via REST API or SDK. The message can target specific tags, a subset of registrations, or all devices. The hub then processes the send request: it queries its registration database for matching devices, groups them by platform, and sends the notification to each PNS using the appropriate protocol and authentication.
Platform Delivery: Each PNS delivers the notification to the device. If the device is offline, the PNS may store the notification and deliver it when the device comes back online (subject to each PNS's policy).
Key Components, Values, Defaults
Namespace: A container for one or more notification hubs. Each namespace has a unique name (e.g., "mynamespace").
Notification Hub: The actual hub where registrations are stored. A namespace can have multiple hubs.
Registration: A record containing the device handle, platform type, tags, and a unique Registration ID. Registrations can be created via the device app (using the device SDK) or via the backend.
Installation: A newer, richer registration model that includes additional metadata like user ID, expiry time, and push variables. Installations are the recommended approach for new development.
Tags: String identifiers used for targeting. Tags are case-sensitive and can be combined using Boolean expressions (e.g., "(tag1 || tag2) && !tag3").
Templates: Platform-agnostic message formats that allow you to send a single notification payload and have the hub transform it into platform-specific formats. Templates use expressions like $(param) for substitution.
Default TTL: Notifications have a default Time-to-Live of 3 days (259200 seconds) for FCM and 30 days for APNs. This can be overridden per notification.
Retry Policy: The hub retries delivery up to 3 times with exponential backoff (1 second, 2 seconds, 4 seconds) if the PNS returns a transient error.
Throttling: The hub can handle up to 1 million notifications per second per hub (at standard tier). There are also per-namespace limits.
Configuration and Verification Commands
To create a notification hub using Azure CLI:
az notification-hub namespace create --resource-group myGroup --name myNamespace --location eastus --sku Basic
az notification-hub create --resource-group myGroup --namespace-name myNamespace --name myHubTo list access policies:
az notification-hub authorization-rule list --resource-group myGroup --namespace-name myNamespace --notification-hub-name myHubTo send a test notification:
az notification-hub test-send --resource-group myGroup --namespace-name myNamespace --notification-hub-name myHub --notification-format apple --payload '{"aps":{"alert":"Test"}}'Interaction with Related Technologies
Azure App Service: Notification Hubs can be integrated with App Service Mobile Apps for automatic registration.
Azure Functions: Can be used as a backend to send notifications triggered by events.
Azure Logic Apps: Connector available for sending notifications.
Azure Event Grid: Can subscribe to hub events like notification delivery failures.
Azure Monitor: Provides metrics like incoming messages, successful deliveries, and registration count.
Platform-Specific Details
APNs (Apple): Uses token-based authentication (JWT) or certificate-based. Token-based is recommended. The hub connects to APNs on port 443 or 2197. Payload size limit: 4KB.
FCM (Android): Uses API key (legacy) or OAuth 2.0. Payload size limit: 4KB. Supports both notification and data messages.
WNS (Windows): Uses OAuth 2.0 with client secret. Payload size limit: 5KB.
Baidu (China): Uses API key and secret key.
Best Practices
Use Installations instead of Registrations for richer metadata.
Use Tags for targeted sends; avoid sending to all devices unless necessary.
Use Templates for localization and platform-specific formatting.
Enable Test Send in the portal to verify connectivity.
Monitor Notification Hub metrics for delivery failures and adjust retry logic.
Use Notification Hubs SDK for device-side registration to simplify code.
Common Pitfalls
Incorrect PNS credentials: The most common issue. Ensure the APNs certificate or FCM API key is correct and not expired.
Missing platform support: Not all platforms are enabled by default. You must configure each PNS in the hub.
Tag mismatch: Tags are case-sensitive. Ensure the backend sends tags that match the device registrations.
Payload size limit: Exceeding the 4KB limit for APNs/FCM will cause delivery failure.
Device token expiry: APNs tokens can change; the hub automatically removes invalid tokens on delivery failure.
Scaling Considerations
Standard tier supports up to 10 million devices per hub, 1 million notifications per second.
Basic tier supports 500,000 devices, 200,000 notifications per second.
For higher scale, use multiple hubs in a namespace or multiple namespaces.
Use partitioned registrations with tags to improve query performance.
Security
Access is controlled via Shared Access Signature (SAS) tokens with different permissions (Listen, Send, Manage).
Use DefaultFullSharedAccessSignature only for management; use Listen and Send for device and backend respectively.
Regenerate keys periodically.
Troubleshooting
Use Test Send in the portal to verify the hub can reach the PNS.
Check Azure Monitor for delivery failure logs.
Enable diagnostic logs for detailed error messages.
Common error codes: 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), 410 (device token invalid).
Configure Platform Notification Systems
In the Azure portal, navigate to your Notification Hub and under 'Settings', select each platform (Apple, Google, Windows, etc.). For Apple, upload the APNs certificate (or token key) and select the environment (Sandbox/Production). For Google, enter the FCM server key (legacy) or OAuth 2.0 credentials. For Windows, provide the Package SID and client secret. These credentials are used by the hub to authenticate with the respective PNS when sending notifications. Incorrect credentials will result in authentication failures (401).
Register Device with Notification Hub
On the device app, obtain a push handle from the PNS (e.g., device token from APNs, registration token from FCM). Then, using the Azure Notification Hubs SDK (e.g., `NotificationHub` class in Android), call `register` or `createOrUpdateInstallation` with the handle and tags. The hub stores the registration in its database with a unique Registration ID. The SDK handles the HTTP call to the hub's REST endpoint. For installations, additional metadata like user ID can be included.
Send Notification from Backend
Your backend application (e.g., an Azure Function, a web app) constructs a notification message. It calls the hub's send API (e.g., `SendNotificationAsync` in C# SDK) specifying the notification payload, target tags (or `$default` for all), and platform. The hub validates the SAS token, queries its registration database for matching devices, and groups them by platform. It then transforms the payload into platform-specific format (if using templates) and sends to each PNS.
Hub Dispatches to PNS
For each platform group, the hub opens a connection to the respective PNS (APNs, FCM, WNS) using the stored credentials. It sends the notification payload within the size limits (4KB for APNs/FCM, 5KB for WNS). The PNS may return an error (e.g., invalid token, payload too large). The hub handles retries for transient errors (up to 3 times with exponential backoff). If a token is invalid (e.g., 410 for APNs), the hub automatically removes the registration.
PNS Delivers to Device
The PNS delivers the notification to the target device. If the device is offline, the PNS stores the notification for a limited time (e.g., APNs stores up to 30 days, FCM up to 28 days). When the device comes online, it receives the notification. The device OS then displays the notification based on the payload (alert, badge, sound). The hub does not track final delivery to the device; it only tracks delivery to the PNS. For end-to-end tracking, use feedback from the device app.
Enterprise Scenario 1: Retail Mobile App
A large retail chain uses Azure Notification Hubs to send personalized promotions and order updates to millions of users across iOS and Android. The backend system tags each user with their user ID and interests (e.g., 'category:electronics'). When a flash sale starts, the backend sends a single notification targeted to all users tagged with 'category:electronics'. The hub fans out to 2 million devices within seconds. They use templates to localize the message: the payload includes parameters like {{name}} and {{discount}}, and the hub substitutes them based on each user's language preference stored in tags. Common issues: if the FCM API key expires, all Android deliveries fail. They monitor hub metrics and set up alerts for delivery failures. Scale: 5 hubs across 2 namespaces, handling 500,000 notifications per minute during peak.
Enterprise Scenario 2: Social Media Platform
A social media app sends real-time notifications for likes, comments, and friend requests. They use installations to store user metadata and push variables. Notifications are sent via Azure Functions triggered by Event Grid events (e.g., new comment). The function calls the hub with the recipient's user tag 'user:123'. The hub delivers to all devices registered under that user (phone and tablet). They use APNs token-based authentication for better security. Misconfiguration: initially they used certificate-based APNs which expired after a year, causing a massive outage. They switched to token-based which doesn't expire. Performance: they achieve 99.9% delivery rate to PNS with average latency under 5 seconds.
Enterprise Scenario 3: News App
A news organization sends breaking news alerts to millions of subscribers. They use tags for topics (e.g., 'topic:politics', 'topic:sports'). Subscribers can opt-in to specific topics. The backend sends a notification to all devices tagged with the relevant topic. They use templates to format the message for each platform (APNs alert, FCM data message). To handle high volume, they use multiple hubs partitioned by region. They also use the Test Send feature to verify connectivity before major events. Common pitfall: if the payload exceeds 4KB due to a long article title, deliveries fail silently. They validate payload size before sending.
What AZ-204 Tests on Notification Hubs (Objective 5.1)
The exam focuses on:
Understanding the architecture: namespace, hub, registrations, installations, tags, templates.
Ability to configure PNS credentials (APNs, FCM, WNS) in the portal.
Implementing device registration using SDKs (especially the difference between register and createOrUpdateInstallation).
Sending notifications with tags and templates.
Understanding the send flow: backend -> hub -> PNS -> device.
Interpreting error codes and troubleshooting.
Choosing between Basic and Standard tiers based on scale.
Common Wrong Answers and Why
'Notifications are guaranteed to be delivered to the device' - Wrong. The hub only guarantees delivery to the PNS. Final delivery depends on the device being online and PNS policies.
'Templates can only be used for localization' - Wrong. Templates can also be used for platform-specific formatting (e.g., different payload structures for APNs vs FCM).
'Tags must be defined in the hub before registration' - Wrong. Tags are arbitrary strings; they can be created on the fly during registration. The hub does not enforce a predefined list.
'Installations and registrations are interchangeable' - Wrong. Installations are the newer model with richer metadata (push variables, expiry). Registrations are legacy. The exam may ask which to use for new development.
Specific Numbers and Terms
Tier limits: Basic - 500,000 devices, 200,000 notifications/sec; Standard - 10 million devices, 1 million notifications/sec.
Payload size: APNs/FCM 4KB, WNS 5KB.
Default TTL: 3 days for FCM, 30 days for APNs.
Retry: 3 attempts with exponential backoff (1s, 2s, 4s).
Ports: APNs 443 or 2197.
Authentication: APNs token (JWT) vs certificate; FCM API key vs OAuth 2.0.
Edge Cases and Exceptions
If a device token changes (e.g., APNs re-issues token), the hub automatically removes the old registration after a failed send (410 error).
Templates with missing parameters will cause substitution to fail; the notification is not sent.
Tag expressions support &&, ||, ! with parentheses, but no wildcards.
The hub does not support sending to individual devices by Registration ID directly; you must use tags or installation ID.
How to Eliminate Wrong Answers
If an answer suggests that the hub ensures delivery to the device, eliminate it.
If an answer says you must define tags first, eliminate it.
If an answer confuses registrations with installations, check the context: new development uses installations.
If an answer mentions a feature not available in the Basic tier (e.g., templates), verify the tier. Templates are available in both tiers.
If an answer says you need to manage PNS connections yourself, eliminate it; that's the whole point of Notification Hubs.
Notification Hubs abstract multiple PNS (APNs, FCM, WNS) behind a single API.
Use installations instead of registrations for new development.
Tags are case-sensitive and support Boolean expressions for targeting.
Templates allow platform-agnostic payloads with parameter substitution.
The hub guarantees delivery to the PNS, not to the device.
Basic tier supports up to 500,000 devices; Standard up to 10 million.
APNs payload limit is 4KB; FCM 4KB; WNS 5KB.
Default TTL: 3 days for FCM, 30 days for APNs.
Retry policy: 3 attempts with exponential backoff (1s, 2s, 4s).
Invalid device tokens are automatically removed from the hub after a failed send.
Use Test Send in the portal to verify PNS connectivity.
Monitor delivery failures via Azure Monitor metrics.
SAS tokens control access with Listen, Send, Manage permissions.
Tier differences: Basic lacks advanced telemetry and scheduled sends.
APNs token-based authentication is preferred over certificate-based.
These come up on the exam all the time. Here's how to tell them apart.
Registrations
Legacy model, still supported.
Stores device handle, tags, and platform.
Limited metadata (no user ID, expiry, push variables).
Update requires full re-registration.
Managed via `register` method in SDK.
Installations
Newer, recommended model.
Stores device handle, tags, platform, and additional metadata (user ID, expiry, push variables).
Supports partial updates via `patch` operation.
Can include installation ID for targeted sends.
Managed via `createOrUpdateInstallation` method.
Mistake
Azure Notification Hubs guarantees delivery to the device.
Correct
The hub only guarantees delivery to the PNS (APNs, FCM, etc.). Final delivery to the device depends on the device being online and the PNS's own delivery policies. The hub cannot control whether the device receives the notification after it leaves the PNS.
Mistake
Tags must be pre-registered in the hub before they can be used.
Correct
Tags are arbitrary strings that can be assigned during device registration. There is no need to define them in advance. The hub automatically indexes them for querying.
Mistake
You can send notifications directly to a specific device using its Registration ID.
Correct
The send API does not accept Registration IDs. To target a specific device, you must use tags (e.g., a unique user ID or installation ID) and include that tag in the device's registration.
Mistake
Templates are only for localization.
Correct
Templates can also be used to define platform-specific payload structures. For example, you can define one template for APNs that includes 'aps' dictionary and another for FCM that includes 'data' and 'notification' objects. They are not limited to language translation.
Mistake
The Basic tier supports all features of the Standard tier.
Correct
The Basic tier has lower scale limits (500,000 devices vs 10 million) and does not support advanced telemetry (e.g., per-message telemetry). It also lacks some features like scheduled sends and batch imports. Always check the documentation for tier differences.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A registration is the legacy model that stores the device handle, tags, and platform. It has limited metadata and requires full re-registration to update. An installation is the newer model that supports additional metadata like user ID, expiry time, and push variables. Installations can be partially updated using PATCH operations. For new development, always use installations.
Tag each device registration with a unique user identifier, e.g., 'user:123'. When sending, target that tag (e.g., 'user:123'). The hub will deliver to all devices registered with that tag. This allows a user to receive notifications on both their phone and tablet.
When the hub attempts to send a notification and the PNS returns an error indicating an invalid token (e.g., APNs 410), the hub automatically removes the registration from its database. Subsequent sends will not attempt delivery to that token. The device app should re-register with a new token on next launch.
Yes, you can send to all devices by omitting tags or using the expression '($default)'. However, for targeted sends, tags are required. There is no built-in way to send to a single device by registration ID; you must use a unique tag per device.
For APNs and FCM, the maximum payload size is 4KB (4096 bytes). For WNS, it is 5KB. Exceeding these limits will cause the PNS to reject the notification. The hub does not automatically truncate the payload.
First, use the Test Send feature in the Azure portal to verify connectivity to the PNS. Check Azure Monitor metrics for 'Incoming Messages' and 'Notification Hubs - Outbound Messages'. Enable diagnostic logs for detailed error codes (e.g., 401 for auth failure, 410 for invalid token). Also verify that the device is online and the app is configured correctly.
The Basic tier supports up to 500,000 devices and 200,000 notifications per second. The Standard tier supports up to 10 million devices and 1 million notifications per second. Standard also includes advanced telemetry, scheduled sends, and batch import/export of registrations. Templates and tags are available in both tiers.
You've just covered Azure Notification Hubs for Push Notifications — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?