Comparison

Messaging Patterns Comparison

ServicePatternDescriptionArchitecture
Storage QueueSimple QueueBasic FIFO message queueProducer → [Queue] → Consumer
Service Bus QueuePoint-to-PointEnterprise messaging queueProducer → [Queue] → Consumer
Service Bus TopicPublish-SubscribeFan-out to multiple subscribersProducer → [Topic] → Multiple Subscriptions
Event HubEvent StreamingHigh-throughput event ingestionProducer → [Event Hub] → Multiple Consumer Groups

Throughput & Scale Comparison

FeatureStorage QueueService Bus QueueService Bus TopicEvent Hub
Max Throughput20,000 msgs/sec2,000 msgs/sec (Standard)
100,000 msgs/sec (Premium)
2,000 msgs/sec (Standard)
100,000 msgs/sec (Premium)
Millions of events/sec
Message Size64KB256KB (Standard)
1MB (Premium)
256KB (Standard)
1MB (Premium)
1MB per event
Queue/Topic LimitUnlimited queues10,000 queues/namespace10,000 topics/namespace32 partitions/hub
RetentionUntil consumed
(7 days max)
Until consumed (max 14 days)Until consumed (max 14 days)1-7 days (configurable)
Storage Limit500TB per account80GB (Standard)
1TB (Premium)
80GB (Standard)
1TB (Premium)
Unlimited

Delivery Guarantees & Features

FeatureStorage QueueService Bus QueueService Bus TopicEvent Hub
OrderingBest-effort FIFOFIFO guaranteed (When using sessions)FIFO guaranteed (per-subscription when using sessions)Per-partition ordering
DeliveryAt-least-onceAt-least-onceAt-least-onceAt-least-once
TransactionsNoFull ACID supportFull ACID supportNo
Dead Letter QueueManual implementationBuilt-inBuilt-inManual implementation
Duplicate DetectionNoYesYesNo
Message TTL7 days max14 days max14 days max7 days max
BatchingYes (32 messages)YesYesYes (up to 1MB)

Consumer Patterns

FeatureStorage QueueService Bus QueueService Bus TopicEvent Hub
ConsumersMultiple competingSingle active consumerMultiple independent subscriptionsMultiple consumer groups
Message ConsumptionDestructiveDestructiveDestructiveNon-destructive (replay)
Load BalancingCompeting consumersCompeting consumersPer-subscription competingPartition-based
FilteringClient-side onlyBasicAdvanced SQL-like filtersClient-side only
Peek SupportYesYesYesNo
Session SupportNoYesYesNo

Security & Authentication

FeatureStorage QueueService Bus QueueService Bus TopicEvent Hub
AuthenticationStorage Account Key
SAS Token
Azure AD
Connection String
SAS Token
Azure AD
Connection String
SAS Token
Azure AD
Connection String
SAS Token
Azure AD
Network SecurityPrivate Endpoints
Firewall Rules
Private Endpoints
Firewall Rules
Private Endpoints
Firewall Rules
Private Endpoints
Firewall Rules
EncryptionAt rest & in transitAt rest & in transitAt rest & in transitAt rest & in transit
RBAC SupportYesYesYesYes

Cost Structure

FeatureStorage QueueService Bus QueueService Bus TopicEvent Hub
Pricing ModelPer operation
($0.0036 per 10K ops)
Per operation + base cost
($0.05 per million ops)
Per operation + base cost
($0.05 per million ops)
Throughput Units
($22.50/TU/month)
Base CostNone677/month (Premium)677/month (Premium)1 TU included
Relative Cost$ (Cheapest)$ (Medium)$$ (Higher)$ (High volume)
$$ (Low volume)
Free TierYes (12 months)NoNoNo

Management & Operations

FeatureStorage QueueService Bus QueueService Bus TopicEvent Hub
Setup ComplexityVery SimpleMediumHighMedium
MonitoringAzure Monitor
Storage Analytics
Azure Monitor
Service Bus Metrics
Azure Monitor
Service Bus Metrics
Azure Monitor
Event Hub Metrics
SDK SupportAll major languagesAll major languagesAll major languagesAll major languages
REST APIYesYesYesYes
Management ToolsStorage Explorer
Azure Portal
Service Bus Explorer
Azure Portal
Service Bus Explorer
Azure Portal
Event Hub Explorer
Azure Portal

Use Case Recommendations for VM Lifecycle management: [azure-event-grid-and-storage-queue-for-vm-events]

ServiceBest ForAvoid WhenYour Use Case Fit
Storage Queue• Simple message processing
• Cost-sensitive scenarios
• Basic queuing needs
• High-volume simple tasks
• Need guaranteed ordering
• Complex enterprise features
• Transactional requirements
✅ Perfect for VM lifecycle events
Service Bus Queue• Enterprise integration
• Guaranteed FIFO ordering
• Transactional processing
• Complex business logic
• High-volume scenarios
• Cost-sensitive applications
• Simple use cases
⚠️ Overkill for your current needs
Service Bus Topic• Multiple consumer teams
• Fan-out messaging
• Advanced filtering needs
• Microservices coordination
• Single consumer
• High-volume streaming
• Simple point-to-point
⚠️ Complex for single consumer
Event Hub• Real-time analytics
• IoT telemetry
• High-throughput streaming
• Event replay requirements
• Low-volume scenarios
• Simple message processing
• Cost-sensitive applications
❌ Overkill for your volume

Performance Characteristics

MetricStorage QueueService Bus QueueService Bus TopicEvent Hub
LatencyLow (< 10ms)Medium (10-50ms)Medium (10-50ms)Very Low (< 5ms)
Availability SLA99.9%99.9%99.9%99.9%
Geo-replicationYes (GRS, RA-GRS)No (Premium: Geo-DR)No (Premium: Geo-DR)Yes (Geo-DR)
Auto-scalingAutomaticManual (Premium: Auto)Manual (Premium: Auto)Manual/Auto

For the concept of ‘Subscription’ for ‘service bus’

Subscriber pattern always means: fully duplicated message across multiple subscribers.

  • subscribers are NOT for loadbalancing.
  • queue is for loadbalancing.

So whenever you see ‘subscription’, it means, ‘duplicated message delivery’, and it is for ALL messages.

For kafka:

  • Consumer Groups == Service Bus Subscriptions
  • Consumers within a grop == Compete for messages (load balancing)
  • Different consumer groups means: each get all messages (duplication)

For Kafka: parition vs consumer group

  1. Message Placement (Producer Side) Messages are distributed to partitions based on:
  • specific partition key (if provided)
  • partition hash of the message key
  • round-robin assignment if no key is provided
  1. Consumer Assignment (Consumer Side) Within each consumer group, each partition is assigned to exactly one consumer:

Key Insights About Partitions:

  1. Ordering Guarantee
  • Within a partition: Messages are strictly ordered
  • Across partitions: No ordering guarantee
  1. Scaling Limitations
  • Maximum consumers per group = Number of partitions
  • If you have 3 partitions, you can have at most 3 consumers in a group
  1. Consumer Rebalancing
  • When consumers join/leave a group, partitions are reassigned

[kafka-partition-performance-and-some-tradeoffs]