🔒 Guided

Pre-launch preview. Authorised access only.

Incorrect code

Guided by A Guide to Cloud
Explore AB-900 AI-901
Guided AZ-305 Domain 4
Domain 4 — Module 4 of 12 33%
22 of 30 overall

AZ-305 Study Guide

Domain 1: Design Identity, Governance, and Monitoring Solutions

  • Monitoring & Logging Design
  • Choosing Authentication Methods
  • Designing Identity Management
  • Authorizing Access to Resources
  • Secrets, Keys & Certificates
  • Governance at Scale
  • Compliance & Identity Governance

Domain 2: Design Data Storage Solutions

  • Relational Data: Choosing Your SQL Platform
  • Database Performance & Scalability
  • Database Security & Compliance
  • Cosmos DB & Semi-Structured Data
  • Blob, Data Lake & Azure Files
  • Data Integration & Analytics

Domain 3: Design Business Continuity Solutions

  • Recovery Objectives: RPO, RTO & SLA Free
  • Backup & Recovery for Compute Free
  • Backup for Databases & Unstructured Data Free
  • High Availability for Compute Free
  • High Availability for Data Free

Domain 4: Design Infrastructure Solutions

  • Compute Design: VMs & When to Use Them
  • Container Solutions: AKS, ACI & Container Apps
  • Serverless & Batch Processing
  • Messaging Architecture
  • Event-Driven Architecture
  • API Integration & Caching
  • App Configuration & Automated Deployment
  • Migration Strategy & Assessment
  • Executing Migrations
  • Network Connectivity: Internet & Hybrid
  • Network Security & Performance
  • Load Balancing & Routing

AZ-305 Study Guide

Domain 1: Design Identity, Governance, and Monitoring Solutions

  • Monitoring & Logging Design
  • Choosing Authentication Methods
  • Designing Identity Management
  • Authorizing Access to Resources
  • Secrets, Keys & Certificates
  • Governance at Scale
  • Compliance & Identity Governance

Domain 2: Design Data Storage Solutions

  • Relational Data: Choosing Your SQL Platform
  • Database Performance & Scalability
  • Database Security & Compliance
  • Cosmos DB & Semi-Structured Data
  • Blob, Data Lake & Azure Files
  • Data Integration & Analytics

Domain 3: Design Business Continuity Solutions

  • Recovery Objectives: RPO, RTO & SLA Free
  • Backup & Recovery for Compute Free
  • Backup for Databases & Unstructured Data Free
  • High Availability for Compute Free
  • High Availability for Data Free

Domain 4: Design Infrastructure Solutions

  • Compute Design: VMs & When to Use Them
  • Container Solutions: AKS, ACI & Container Apps
  • Serverless & Batch Processing
  • Messaging Architecture
  • Event-Driven Architecture
  • API Integration & Caching
  • App Configuration & Automated Deployment
  • Migration Strategy & Assessment
  • Executing Migrations
  • Network Connectivity: Internet & Hybrid
  • Network Security & Performance
  • Load Balancing & Routing
Domain 4: Design Infrastructure Solutions Premium ⏱ ~15 min read

Messaging Architecture

Azure Service Bus, Queue Storage, and message patterns — design reliable asynchronous communication between services with guaranteed delivery and ordering.

Why messaging architecture matters

☕ Simple explanation

Messaging is how services talk without waiting for each other. Instead of Service A calling Service B directly (and waiting), Service A puts a message in a queue, and Service B processes it when ready.

This decoupling means: if Service B goes down, messages wait safely in the queue. If Service B is slow, messages buffer. If you need 10x throughput, add more consumers.

Two Azure services: Queue Storage (simple, cheap, high volume) and Service Bus (enterprise-grade with ordering, sessions, transactions, dead-lettering).

Messaging architecture is about commands and brokered delivery — ensuring reliable, ordered communication between services. While Service Bus can also carry business events that require guaranteed delivery, the core pattern is command processing (do something) as opposed to reactive notifications (something happened — covered in the Event-Driven Architecture module).

  • Point-to-point queues: One sender, one receiver — work distribution
  • Publish-subscribe topics: One sender, many receivers — fan-out notifications
  • Message ordering and sessions: FIFO processing, grouped messages
  • Dead-lettering: Handle poison messages that can’t be processed

Queue Storage vs Service Bus

Azure Queue Storage vs Service Bus Queues
FactorQueue StorageService Bus Queues
ProtocolHTTP/HTTPS (REST)AMQP 1.0, HTTP/HTTPS
Max message size64 KB256 KB (Standard) / 100 MB (Premium)
Max queue sizeUnlimited (storage account limit)1-80 GB
Message orderingNot guaranteed (best-effort FIFO)Guaranteed FIFO (with sessions)
Duplicate detectionNoYes (built-in)
Dead-letter queueNo — poison messages need custom handlingYes — automatic dead-letter sub-queue
TransactionsNoYes — atomic send/complete across messages
SessionsNoYes — group related messages for ordered processing
Topics (pub-sub)No — queues onlyYes — topics with subscriptions and filters
CostVery low (~$0.0004/10K operations)Higher (~$0.05/million operations Premium)
Best forSimple queuing, high volume, cost-sensitiveEnterprise messaging, ordering, transactions, pub-sub

🚀 Marcus’s messaging design: NovaSaaS uses Service Bus:

  • Queues for order processing (guaranteed FIFO with sessions per customer)
  • Topics for notifications (one order event fans out to: billing, inventory, email, analytics)
  • Dead-letter queue catches poison messages for investigation
  • Duplicate detection prevents double-processing when retries occur

🏗️ Priya’s cost-conscious choice: GlobalTech’s non-critical log ingestion uses Queue Storage — millions of messages per day at minimal cost, ordering doesn’t matter, messages are simple JSON.

💡 Exam tip: Queue Storage vs Service Bus — keyword signals

Queue Storage: “simple queuing,” “high volume,” “cost-sensitive,” “messages under 64 KB,” “no ordering needed”

Service Bus: “enterprise,” “guaranteed ordering,” “FIFO,” “transactions,” “dead-letter,” “pub-sub,” “topics,” “sessions,” “duplicate detection”

If ANY of the Service Bus keywords appear in the scenario, choose Service Bus.

Service Bus Premium vs Standard

FactorStandardPremium
ThroughputShared (variable)Dedicated (predictable)
Message size256 KB100 MB
VNet integrationNoYes (private endpoints)
Geo-DRNoYes (metadata replication)
Best forDev/test, moderate workloadsProduction, compliance, high throughput

Common messaging patterns

PatternDescriptionImplementation
Competing consumersMultiple consumers process from one queueScale out processing by adding consumers
Fan-outOne message triggers multiple actionsService Bus topic with multiple subscriptions
Load levellingBuffer burst trafficQueue absorbs spikes, consumers process at steady rate
Saga patternDistributed transactions across servicesChoreography via messages or orchestration via Durable Functions

Knowledge check

Question

When should you recommend Service Bus over Queue Storage?

Click or press Enter to reveal answer

Answer

When you need: FIFO ordering (sessions), dead-letter queues, duplicate detection, transactions, pub-sub topics, messages over 64 KB, or AMQP protocol. Queue Storage is for simple, high-volume, cost-sensitive queuing where ordering and enterprise features aren't needed.

Click to flip back

Question

What is the dead-letter queue in Service Bus?

Click or press Enter to reveal answer

Answer

A sub-queue that automatically captures messages that can't be processed (exceeded max delivery count, TTL expired, or filter evaluation exceptions). Prevents poison messages from blocking the main queue. Applications can read dead-lettered messages for investigation and manual retry.

Click to flip back

Question

How do Service Bus topic subscriptions enable the pub-sub pattern?

Click or press Enter to reveal answer

Answer

A topic receives messages from publishers. Multiple subscriptions on that topic each get their own copy of matching messages. Subscriptions can have SQL-like filters (e.g., 'Region = EU' or 'Amount > 10000') so each subscriber only receives relevant messages. This decouples publishers from subscribers and enables content-based routing without code changes.

Click to flip back

Knowledge Check

🚀 NovaSaaS processes customer orders that must be handled in exact sequence per customer. If a message can't be processed after 3 attempts, it should be moved aside for investigation without blocking other orders. Which service should Marcus recommend?

Knowledge Check

🏦 FinSecure Bank processes loan applications. Each application must be reviewed by both the credit team AND the compliance team simultaneously. High-value loans (over €1M) must also be routed to the executive review team. All teams process independently. Which messaging pattern should Elena recommend?

🎬 Video coming soon


Next up: Messages are commands. Events are notifications — Event-Driven Architecture.

← Previous

Serverless & Batch Processing

Next →

Event-Driven Architecture

Guided

I learn, I simplify, I share.

A Guide to Cloud YouTube Feedback

© 2026 Sutheesh. All rights reserved.

Guided is an independent study resource and is not affiliated with, endorsed by, or officially connected to Microsoft. Microsoft, Azure, and related trademarks are property of Microsoft Corporation. Always verify information against Microsoft Learn.