Application Architecture Fundamentals
Azure Service BusA fully managed enterprise message broker supporting queues (point-to-point, FIFO with sessions) and topics/subscriptions (publish-subscribe). Guarantees at-least-once delivery, message ordering, dead-lettering, and transactions. Best for business process decoupling, command distribution, and reliable messaging between services.Azure Event GridA fully managed event routing service based on the publish-subscribe pattern. Routes discrete events (resource state changes, custom events) to multiple subscribers. Zero infrastructure management; pay per event. Best for event-driven reactive architectures and Azure resource event notifications.Azure Event HubsA big data streaming platform for high-throughput telemetry ingestion (millions of events per second). Supports Apache Kafka protocol. Provides event partitioning, consumer groups, and 1–90 day retention. Best for log aggregation, telemetry ingestion, and real-time data pipelines.Azure API ManagementA fully managed API gateway that provides request routing, rate limiting, authentication (OAuth, JWT, subscription keys), request/response transformation, caching, and analytics. Acts as the single entry point (facade) for backend microservices or legacy APIs.Azure Cache for RedisA fully managed in-memory data store for caching, session state, pub/sub, and sorted sets. Reduces database query load and latency for frequently read data. Supports data persistence, geo-replication (Premium tier), and clustering for high-throughput scenarios.Messaging Service Selection
| Service | Pattern | Throughput | Use Case |
|---|---|---|---|
| Service Bus Queue | Point-to-point | Medium | Ordered processing, transactions |
| Service Bus Topic | Publish-subscribe | Medium | Fan-out to multiple consumers |
| Event Grid | Event notification | Low-Medium | Reactive architecture, webhooks |
| Event Hubs | Streaming | Very High | Telemetry, log ingestion, Kafka |
| Storage Queue | Simple queue | Low | Simple, durable, cheap queue |
Key Architectural Patterns
Event-Driven Architecture: Services communicate via events through a broker. Producers emit events; consumers react. Decoupled, scalable, but eventual consistency.
CQRS (Command Query Responsibility Segregation): Separate read (Query) and write (Command) data models. Write model: optimized for transactions. Read model: optimized for queries with denormalized views, caching. Enables independent scaling of reads and writes.
API Gateway Pattern: Single entry point for all client requests. APIM routes, authenticates, throttles, and transforms before forwarding to backend services. Hides backend complexity from clients.
Cache-Aside Pattern: Application checks cache first; on miss, fetches from database and populates cache with TTL. Reduces database load for frequently read, slowly changing data.
Design Patterns Deep Dive
Messaging Pattern Comparison
CQRS Architecture
| Aspect | Command Side (Write) | Query Side (Read) |
|---|---|---|
| Model | Normalized for integrity | Denormalized for performance |
| Storage | SQL Database (ACID) | Redis / Cosmos DB / read replicas |
| Consistency | Strong | Eventual (async sync) |
| Scaling | Independently scalable | Read replicas, cache layer |
| Use Case | Order creation, user updates | Product catalog, dashboards |
Azure API Management Architecture Patterns
External API Gateway (public-facing)
- Rate limiting per subscription key
- OAuth 2.0 / JWT validation
- Response caching for static data
- Request transformation (SOAP-to-REST, versioning)
Internal API Gateway (microservices aggregation)
- Service discovery and routing
- Load balancing between backend versions
- Circuit breaker policies (retry, timeout)
- Backend for Frontend (BFF) per client type
N-Tier Architecture on Azure
| Tier | Service Options | Pattern |
|---|---|---|
| Presentation | Static Web Apps, App Service (frontend) | CDN-served static assets |
| API | App Service (backend), Functions, APIM | RESTful, GraphQL |
| Business Logic | AKS microservices, Service Bus consumers | Event-driven or synchronous |
| Data | SQL Database, Cosmos DB, Redis | Polyglot persistence |
| Cache | Azure Cache for Redis | Cache-aside, session state |
Azure App Configuration
Centralized feature flags and configuration management:
- Feature flags: Enable/disable features without redeployment
- Dynamic configuration: Update app settings without restart
- Integrate with Key Vault references for secrets
- Supports .NET, Java, Python, JavaScript SDKs
Hands-On: Configure Service Bus with Topics and Subscriptions
Step 1: Create Service Bus Namespace
- Navigate to Service Bus > Create
- Configure namespace name, pricing tier: Standard (topics) or Premium (VNet, private endpoint)
- Review and create
Step 2: Create Topic and Subscriptions
- Open Service Bus namespace > Topics > + Topic
- Name:
order-events, max size: 1 GB, TTL: 14 days - Click topic > Subscriptions > + Subscription
- Create subscriptions:
billing-service,inventory-service,notification-service - Each subscription receives an independent copy of every message published to the topic
Step 3: Create Azure API Management
- Navigate to API Management > Create
- Configure organization name, email, pricing tier (Developer for testing, Standard for production)
- After creation, go to APIs > Add API > HTTP
- Configure frontend URL and backend URL
- Add Policy on the inbound layer:
- Rate limiting:
rate-limit-by-keyat 100 calls/minute per subscription key - JWT validation:
validate-jwtto verify OAuth 2.0 tokens
- Rate limiting:
- Test via APIM developer portal
Step 4: Configure Azure Cache for Redis
- Navigate to Azure Cache for Redis > Create
- Tier: Basic (dev/test), Standard (HA replica), Premium (persistence, VNet, clustering)
- After creation, get connection string from Access keys
- Implement cache-aside in application:
var cached = await redis.GetAsync("product:123"); if (cached == null) { var product = await db.Products.FindAsync(123); await redis.SetAsync("product:123", Serialize(product), TimeSpan.FromMinutes(15)); return product; } return Deserialize(cached);
Step 5: Configure Event Grid Subscription
- Navigate to target Azure resource (e.g., Storage Account)
- Go to Events > + Event Subscription
- Configure:
- Event types:
BlobCreated,BlobDeleted - Endpoint type: Azure Function, Webhook, or Service Bus
- Event types:
- Save — events fire automatically when blobs are created/deleted
AZ-305 Exam Focus
AZ-305 tests your ability to select the right messaging service and architectural pattern for a given scenario. Service Bus vs. Event Grid vs. Event Hubs is a classic AZ-305 question type. CQRS and API Management pattern questions also appear frequently.
Exam Trap
Event Grid vs. Event Hubs vs. Service Bus Confusion: These three services are commonly confused. Event Grid = discrete events, reactive architecture, low volume. Event Hubs = streaming, high throughput, telemetry ingestion. Service Bus = reliable business messaging, ordering, transactions, dead-letter queues. Selecting the wrong one is the most common mistake on messaging questions.
Exam Trap
Service Bus Topics Require Standard Tier: Service Bus Queue is available on Basic tier. Topics and subscriptions (publish-subscribe) require Standard or Premium tier. If a scenario requires fan-out to multiple subscribers, Standard tier is the minimum.
Exam Trap
Cache-Aside Is Not Automatic: Azure Cache for Redis does not automatically sync with your database. The cache-aside pattern requires the application to implement: check cache → miss → query DB → write to cache. If the DB changes, the application must either invalidate the cache entry or let it expire via TTL.
Exam Trap
API Management for All Backends: APIM is appropriate for exposing APIs to external consumers and aggregating microservices. It adds latency and cost. For simple single-service web APIs without need for gateway features (rate limiting, auth, transformation), App Service alone is sufficient.
Exam Tip
Event Grid for Azure Resource Events: When a scenario involves reacting to Azure resource state changes (storage blob created, VM started/stopped, policy compliance change), Event Grid is almost always the answer. It natively integrates with Azure services as event sources with zero additional configuration.
Must Memorize
CQRS Benefits: CQRS separates reads and writes. The write side maintains data integrity (SQL, ACID). The read side provides performance (denormalized views, cache, read replicas). The exam tests when CQRS is appropriate: when read and write scalability requirements differ significantly, or when read models need specialized optimization (search, analytics).
Question — click to flip
Q: What is the difference between Azure Service Bus and Azure Event Grid?
Question — click to flip
Q: When should you use Azure Event Hubs instead of Service Bus?
Question — click to flip
Q: What is the CQRS pattern and why would you apply it?
Question — click to flip
Q: What does Azure API Management provide that a simple App Service backend does not?
Question — click to flip
Q: What is the cache-aside pattern and how does Redis implement it?
Question — click to flip
Q: What Azure service subscription tier is required for Service Bus Topics?