Azure Notification Hubs for Push at Scale

Azure Notification Hubs (NH) is a fully managed, multi-platform push notification engine that enables sending high-volume push notifications to any platform (iOS, Android, Windows, Kindle, Baidu) from a single backend. It abstracts the complexity of interacting with each Platform Notification System (PNS) – such as APNs (Apple), FCM (Google), WNS (Microsoft), MPNS (deprecated), and Baidu Cloud Push – by providing a unified API. The primary reason NH exists is to solve the 'fan-out' problem: sending the same notification to millions of devices across different platforms without managing per-platform connections, retries, and token management. Without NH, each application backend would need to maintain persistent connections to every PNS, handle authentication, manage device tokens, and implement retry logic with exponential backoff. NH handles all of this at scale, with built-in telemetry and monitoring.

When a backend application sends a notification, it calls the NH REST API (or uses SDKs). The hub receives the message and performs the following steps:

- Namespace: A container for one or more notification hubs. Each namespace provides a unique endpoint (e.g., https://mynamespace.servicebus.windows.net/). - Notification Hub: The logical entity where registrations are stored and messages are sent. Each hub has a unique connection string (access policy) with listen, send, or manage permissions. - Access Policies: Shared Access Signature (SAS) keys with permissions: Listen (for client devices to register), Send (for backend to send), Manage (for full control). Default policies: DefaultFullSharedAccessSignature and DefaultListenSharedAccessSignature. - Device Registration: Contains: - Platform: e.g., apple, gcm, windows, kindle, baidu. - Handle: Device token (APNs) or registration ID (FCM). - Tags: Up to 60 tags per registration, each up to 120 characters. - Expiry: Registration expires after 90 days of inactivity by default (configurable via SDK). - TTL (Time-to-Live): Default values: APNs – 1 day (24 hours), FCM – 4 weeks (28 days), WNS – 3 days. Can be overridden per message. - Message Size Limits: APNs – 4 KB (4096 bytes), FCM – 4 KB, WNS – 5 KB. For APNs with VoIP payloads, limit is 5 KB. - Template Notifications: Allow sending a single message that is rendered differently per platform. For example, a template can use variables like {{message}} and {{title}}. The hub substitutes values during send. - Batch Send: Up to 1 million devices per send operation. For larger audiences, use multiple sends or use tag expressions for segmentation. - Scale Limits: By default, a namespace supports up to 100 notification hubs. Each hub can have up to 10 million registrations (soft limit, can be increased). Throughput: up to 10 million messages per hour per namespace for the Standard tier. - Pricing Tiers: Free (1 million messages/month, 500 active devices), Basic (10 million messages/month, 200,000 active devices), Standard (unlimited messages, unlimited devices, includes advanced telemetry and scheduling).

To create a notification hub via Azure CLI:

# Create a namespace
az notification-hub namespace create --resource-group myRG --name myNamespace --location eastus --sku Basic

# Create a hub within the namespace
az notification-hub create --resource-group myRG --namespace-name myNamespace --name myHub

# List access policies
az notification-hub authorization-rule list --resource-group myRG --namespace-name myNamespace --notification-hub-name myHub

# Get connection string for send policy
az notification-hub authorization-rule keys list --resource-group myRG --namespace-name myNamespace --notification-hub-name myHub --name DefaultFullSharedAccessSignature

To test sending a notification via REST:

POST https://myNamespace.servicebus.windows.net/myHub/messages?api-version=2015-01 HTTP/1.1
Authorization: SharedAccessSignature sr=myNamespace&sig=...&se=...&skn=DefaultFullSharedAccessSignature
Content-Type: application/json;charset=utf-8
ServiceBusNotification-Format: apple

{
  "aps": {"alert": "Hello from NH!"}
}

A global news organization needs to push breaking news alerts to 50 million mobile devices across iOS, Android, and Windows. They choose Azure Notification Hubs Standard tier because of its unlimited devices and advanced telemetry. They tag each device with categories like world, sports, tech, and per-user tags like user:123. When a breaking story occurs, the backend sends a single notification with a tag expression like world && !user:456 to exclude a specific user. The hub handles the fan-out to all matching registrations (up to 10 million per hub). They use templates to localize the message: the payload includes variables {{title}} and {{body}}, and the hub substitutes locale-specific strings. Performance: they send up to 5 million notifications per minute during peak events. They monitor PNS errors closely; a common issue is expired APNs tokens when users delete and reinstall the app. The hub automatically marks these registrations as expired, but the client must re-register. They also use scheduled notifications for non-urgent stories, queuing them up to 7 days in advance.

An e-commerce platform sends push notifications for order status changes (e.g., 'Shipped', 'Delivered'). They use Notification Hubs to send per-user notifications. Each device is tagged with the user ID (e.g., user:789). When an order status changes, the backend sends a notification with tag user:789. The hub delivers to all devices of that user (phone, tablet). They use direct send for testing. A common misconfiguration: they initially used the Free tier, but exceeded the 1 million messages/month limit, causing throttling (HTTP 403). They upgraded to Basic tier. They also encountered issues with FCM registration IDs expiring after 4 weeks of inactivity; they implemented a background refresh on the client every 2 weeks. They use Azure Monitor alerts to detect spikes in failed deliveries (e.g., >5% failure rate).

A game studio sends invites and friend requests to players. They have 10 million daily active users. They use Notification Hubs with tags like game:fortnite and region:na. They send broadcast notifications for server maintenance. A challenge: they needed to send different payloads to iOS (badge, sound) vs Android (data-only). They use templates with platform-specific rendering. They also use the 'scheduled send' feature for maintenance announcements. A critical incident: during a global event, they sent a broadcast to all 10 million devices, but the hub's tag index lookup caused a few seconds of latency. They optimized by splitting the audience into smaller segments (e.g., by region) and sending multiple messages. They also discovered that the hub's default TTL of 1 day for APNs was too long for time-sensitive invites; they set TTL to 1 hour. They monitor PNS error codes: InvalidRegistration from FCM indicated a corrupted registration ID, which they fixed by updating the client SDK.