Reliability in Azure Notification Hubs

Azure Notification Hubs helps you manage push notifications across multiple platform notification systems (PNS), such as Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM), and Windows Push Notification Service (WNS).

When you use Azure, reliability is a shared responsibility. Azure provides a range of capabilities to support resiliency and recovery. You're responsible for understanding how those capabilities work within all of the services you use, and selecting the capabilities you need to meet your business objectives and uptime goals.

This article describes how to make Notification Hubs resilient to various potential outages and problems, including transient faults, availability zone failures, region-wide failures, and service maintenance. It also describes backup and restore options and key information about the Notification Hubs service-level agreement (SLA).

Production deployment recommendations

For production workloads, follow these recommendations:

Reliability architecture overview

Azure Notification Hubs is organized around namespaces and notification hubs. A namespace is a management boundary that contains one or more hubs. Hubs represent endpoints for an application. Devices register with those endpoints by using either registrations or installations, which enable the service to send push notifications to the devices. For more information, see Registration management.

Notification Hubs sends push notifications to platform notification systems (PNS), such as Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM). End-to-end notification delivery depends on the availability of Notification Hubs and the behavior of downstream PNS providers.

For reliability planning, it's important to distinguish between the following types of data that Notification Hubs manages:

• Metadata: Namespace and hub configuration, including connection information and disaster recovery configuration.
• Registration data: Device registrations and installations that map users and devices to tags and templates.

Resilience to transient faults

Transient faults are short, intermittent failures in components. They occur frequently in a distributed environment like the cloud, and they're a normal part of operations. Transient faults correct themselves after a short period of time. It's important that your applications can handle transient faults, usually by retrying affected requests.

All cloud-hosted applications should follow the Azure transient fault handling guidance when they communicate with any cloud-hosted APIs, databases, and other components. For more information, see Recommendations for handling transient faults.

Notification Hubs automatically handles transient faults that occur when connecting to a PNS. However, you're responsible for handling transient failures when your services or users' devices interact with Notification Hubs. Transient failures can occur during registration operations, notification send operations, and management operations. Follow this guidance:

• Registrations and installations: Your applications on devices should retry registration and installation operations that fail because of transient faults. Microsoft-provided SDKs handle retries automatically. If you can't use the provided SDKs, implement retry logic with exponential backoff and jitter, and make registration operations idempotent where possible.

  Creating or updating an installation is idempotent, so you can safely retry the operation. When possible, use installations instead of registrations.

• Notification sends and management operations: Use a Microsoft-provided SDK to send push notifications and perform management operations. These SDKs automatically retry when transient faults occur.

  If you can't use the provided SDKs, implement retry logic with exponential backoff and jitter, and make notification sending operations idempotent where possible.

Resilience to availability zone failures

Availability zones are physically separate groups of datacenters within an Azure region. When one zone fails, services can fail over to one of the remaining zones.

In regions that support availability zones, Notification Hubs namespaces support a zone-redundant configuration. Notification Hubs automatically enables zone redundancy for all namespaces in some regions. When zone redundancy is enabled, Microsoft replicates both metadata and registration data across all availability zones in the region.

Requirements

• Region support:

  Notification Hubs automatically enables zone redundancy for all namespaces in the following region. You can't disable zone redundancy in these regions:

  Asia Pacific
  China North 3

  In other regions that support Notification Hubs and have availability zones, zone redundancy is optional. You can enable it only when you create a namespace.

• Tier support: You can use availability zones with all tiers of Notification Hubs.

Cost

Zone redundancy incurs an additional charge beyond the tier price. For more information, see Notification Hubs pricing.

Configure availability zone support

• Create a new zone-redundant namespace: The process to create a new zone-redundant namespace depends on the region you use:

  • In regions where Notification Hubs automatically enables zone redundancy, you don't need to configure it.

    Important

    In these regions, Notification Hubs always creates namespaces with zone redundancy enabled, even if a code-based deployment, such as a Bicep file or Azure Resource Manager template, specifies that zone redundancy is disabled.

    If you don't want a zone-redundant namespace, create it in a region that supports optional zone redundancy.

  • In regions where zone redundancy is optional, you can enable it only when you create a namespace. To learn how to set up a new namespace with zone redundancy, see Create an Azure notification hub in the Azure portal.

• Make an existing namespace zone redundant: Notification Hubs doesn't support in-place migration of an existing namespace to availability zone support. You need to deploy a new namespace and move your registrations to that namespace. Follow the guidance in Move resources between Azure regions, which also applies if you deploy the new namespace in the same region.

Behavior when all zones are healthy

This section describes what to expect when you configure a Notification Hubs namespace for zone redundancy, and all zones are operational.

• Cross-zone operation: Notification Hubs automatically distributes and serves requests by using infrastructure in any zone in the region.

• Cross-zone data replication: Both registration data and metadata are synchronously replicated across multiple availability zones in the specified region.

Behavior during a zone failure

This section describes what to expect when you configure a Notification Hubs namespace for zone redundancy, and there's an outage in one of the zones.

• Detection and response: Microsoft detects zone failures and manages failover within the region. You don't need to initiate failover.

• Notification: Azure doesn't automatically notify you when a zone is down. However, you can use Azure Service Health to understand the overall health of the service, including any zone failures, and you can set up Service Health alerts to notify you of problems.

• Active requests: In-flight management operations, device registrations, and new requests to send notifications might fail during failover. Your applications should retry failed operations by following transient fault handling guidance.

• Expected data loss: Data loss isn't expected during a single-zone outage because Notification Hubs synchronously replicates namespace and hub configuration and registration data across availability zones.

  This replication isn't a backup. Under the shared responsibility model, you're responsible for backing up registration and installation data. For more information, see Backup and restore.

• Expected downtime: A brief service interruption is possible while Microsoft reroutes traffic. Follow the transient fault handling guidance to prepare your applications for these interruptions.

• Redistribution: The service automatically redirects requests to healthy zones.

Zone recovery

When the affected zone recovers, you don't need to take any action. Microsoft restores and rebalances Notification Hubs infrastructure to use the recovered zone.

Test for zone failures

You can't trigger a Notification Hubs zone failover directly. To test your workload behavior, run resilience tests for retries, idempotency, and dependency failures in nonproduction environments. You can also use Azure Chaos Studio to test surrounding application components.

Resilience to region-wide failures

Notification Hubs provides metadata disaster recovery by replicating namespace metadata across regions, but it doesn't replicate device registration data. This capability requires manual intervention during a region outage and involves some downtime for your notification hub.

If you need to reduce downtime and manual intervention during failover, consider using a custom multiregion solution.

Custom multiregion solutions for resiliency

Microsoft-managed metadata geo-disaster recovery only replicates metadata. The feature can recover that metadata to a secondary namespace, but you're responsible for importing device registrations into that namespace so your application can continue to operate. This approach requires manual intervention during a disaster and involves downtime.

If your recovery objectives require less downtime or manual intervention, you can implement a custom active-active multiregion solution. Deploy a second Notification Hubs namespace to another Azure region ahead of time.

• Failover: Because the second namespace is a working resource, you can implement logic to detect a region failure and switch to that namespace.

• Synchronization: To keep a second notification hub in sync with the primary notification hub, use one of the following options:

  • For installations: Use an app backend that simultaneously creates and updates installations in both notification hubs. Installations enable you to specify your own unique device identifier, which supports this replication scenario. For more information, see the RedundantHub sample.

  • For registrations: Use an app backend that regularly exports registrations from the primary notification hub as a backup and bulk imports them into the secondary notification hub. For more information, see Export and import Azure Notification Hubs registrations in bulk.

  Alternatively, if you don't have a backend, configure your app to create installations in both hubs when the app starts on target devices. The devices create new registrations in both notification hubs. Eventually the secondary notification hub has all the active devices registered.

• Expired registrations and installations: The secondary notification hub might have expired registrations and installations. When a push is made to an expired handle, Notification Hubs automatically cleans the associated registration or installation record on the notification hub, based on the response received from the PNS server. You can clean expired records from the backup solution of your choice by adding custom logic that processes feedback from each send and removes expired registrations and installations.

• Unopened apps: There's a period of time during which devices with unopened apps don't receive notifications.

• Cost: If you use your own secondary hub to protect registration data, that hub incurs normal service charges. Similarly, if you deploy any other Azure resources into your secondary region to support your recovery, you pay for those at normal service rates.

Backup and restore

Notification Hubs doesn't provide a single built-in backup and restore feature for all of the data stored in your namespace. You're responsible for combining the following approaches:

• Use infrastructure as code (IaC), such as Bicep, to define your namespace, hub, and policy configuration. Store those definitions in source control so that you can redeploy the resources when necessary.
• Back up your device registration data by exporting Azure Notification Hubs registrations in bulk.

An exported registration set provides a recovery point after accidental deletion or unwanted changes. IaC preserves resource configuration, but it doesn't preserve device registration data. For more information about the different roles of redundancy and backup, see Redundancy, replication, and backup.

Resilience to service maintenance

Microsoft regularly applies service updates and performs other maintenance. The Azure platform handles these activities automatically, ensuring that maintenance is seamless and transparent to you. No downtime is expected during maintenance events unless you've been advised through Azure Service Health planned maintenance.

Service-level agreement

The service-level agreement (SLA) for Azure services describes the expected availability of each service and the conditions that your solution must meet to achieve that availability expectation. For more information, see SLAs for online services.

For Notification Hubs, the availability SLA applies to namespaces that use the Basic and Standard tiers.

Related content

• Reliability in Azure