{"id":4508,"date":"2026-10-12T21:32:57","date_gmt":"2026-10-12T21:32:57","guid":{"rendered":"https:\/\/www.examtopics.info\/blog\/?p=4508"},"modified":"2026-10-12T21:32:57","modified_gmt":"2026-10-12T21:32:57","slug":"microsoft-az-305-service-bus-event-grid-event-hubs-api-management","status":"publish","type":"post","link":"https:\/\/www.examtopics.info\/blog\/microsoft-az-305-service-bus-event-grid-event-hubs-api-management\/","title":{"rendered":"Microsoft AZ-305: Service Bus, Event Grid, Event Hubs, and APIs"},"content":{"rendered":"

An online clinic sends appointment confirmations, records device telemetry and exposes a billing API to partner systems. Developers propose putting every event in Service Bus because it guarantees that messages can be queued. But a billing command that must be processed reliably, a notification that several teams should receive, and a high-throughput stream of sensor samples have different delivery and retention requirements. API consumers also need authentication, quotas and versioning. An Azure architect must keep these responsibilities distinct even when the final system connects several managed services.<\/p>\n

Microsoft AZ-305<\/strong> tests messaging, event-driven application architecture and API integration. The existing Azure compute platform comparison<\/a> describes where workers and serverless functions run. This article focuses on what connects those workloads: Azure Service Bus, Event Grid, Event Hubs and API Management, with semantics that remain correct during retries, consumer outages and deployment changes.<\/p>\n

Classify the communication before selecting a service<\/h2>\n

Draw producers, consumers and the business meaning of each message. A command<\/em> asks one logical worker to perform an action, such as issuing an invoice. An event<\/em> states something that happened, such as an invoice being paid. A telemetry record<\/em> is part of a stream that may be aggregated or replayed by several analytical consumers. The same payload format does not make these contracts interchangeable.<\/p>\n

Document expected volume, peak bursts, ordering, retention, fan-out, latency, retry, privacy, and what constitutes completion. If a service accepts a message but no consumer completes it for hours, the user-facing business process may still have failed. Monitoring must follow the operation beyond initial acceptance to its final state.<\/p>\n

Use Service Bus for enterprise work and transaction boundaries<\/h2>\n

Azure Service Bus queues and topics are suitable for supported enterprise messaging patterns that require a managed broker, durable work distribution and structured operational controls. Queues can isolate a producer from a slow consumer; topics and subscriptions can fan out messages according to the selected subscription model. The Service Bus overview<\/a> describes its queuing and publish-subscribe features.<\/p>\n

Use competing consumers for a queue when each logical work item should have one successful business handler, and use subscriptions when different teams require their own copies. Configure lock duration, renewal, dead-letter behavior, duplicate detection and ordering controls to match the actual workload. A queue prevents a temporary consumer outage from forcing the producer to fail immediately; it cannot automatically ensure a payment is never charged twice.<\/p>\n

Use Event Grid for event routing, not an arbitrary work backlog<\/h2>\n

Event Grid routes supported event notifications from publishers to subscribers, including resource change and application events. It can connect event-driven components where producers should not know every consumer. Delivery retries and dead-letter options may be available by tier and target, but an event-routing service should not be mistaken for a durable ordered ledger of all business decisions.<\/p>\n

For a new appointment, a successful business transaction might publish an event so messaging, analytics and support services react independently. Each subscriber must handle duplicate delivery and define what happens if it was offline. Event payloads should contain stable event identifiers and enough context to retrieve authorized business state without exposing patient details unnecessarily.<\/p>\n

Use Event Hubs when the workload is a stream<\/h2>\n

Azure Event Hubs is optimized for ingesting and consuming streams at scale. It fits telemetry, large log feeds and some change streams where consumers need partitioned ordered reads within a partition and time-bounded retention or replay. Partitioning is a capacity and ordering choice: one hot partition key can limit effective throughput while others sit idle. Consumer groups and checkpointing help independent processing applications track progress.<\/p>\n

A telemetry stream is not a good place to store irreversible billing commands merely because it processes large volumes. The application must know whether it needs durable command handling, replayable observation, or a near-real-time feed. Pick an event-stream model only where the downstream processing and data volume justify it, and plan how duplicates or late data affect analytics results.<\/p>\n

Keep irreversible actions idempotent across retries<\/h2>\n

The hardest case is an ambiguous timeout: a worker invokes a payment service that accepts the charge, but the acknowledgment is lost. A new message attempt can trigger a second charge unless the payment operation uses a stable idempotency key or checks authoritative transaction state. A delivery mechanism may retry an operation or lock a message, but it cannot infer the business truth inside an external payment provider.<\/p>\n

For message handlers, choose retry policies with bounded backoff, poison-message routing, and an explicit dead-letter owner. Replaying a dead-letter queue after an incident can re-trigger already completed actions. Record business identifiers, event versions and processing state so manual or automated replay is safe and auditable.<\/p>\n

Use API Management for the partner contract<\/h2>\n

Azure API Management helps publish, secure and operate APIs with supported gateway policies, products, subscriptions, versioning, transformations and observability. Its purpose is different from messaging: it provides a managed API surface to consumers and can route to backend services. It does not turn an unauthenticated backend into a secure business system automatically. Design client authentication, backend authorization, throttling and quotas around the partner relationship.<\/p>\n

An external billing partner should receive only the endpoints, permissions and rate limit necessary for its contract. Handle breaking API changes with a clear versioning or revision policy rather than silently changing response fields in place. A gateway can validate a token format or apply a rate policy while the backend still must enforce customer-level authorization and input validation.<\/p>\n

Design event processing with appropriate compute<\/h2>\n

Azure Functions, Container Apps, app services or other supported worker platforms can consume brokered work, but concurrency and timeout behavior vary. A handler that scales from ten to a thousand instances can overwhelm a relational database or external billing endpoint if the downstream limit is ignored. Pair queue depth with maximum safe processing concurrency and an operating plan for accumulated backlog.<\/p>\n

The highly available Azure applications<\/a> article emphasizes end-to-end dependencies. Applied here, that means designing for a broker outage, consumer failures, network denial, identity expiration and regional recovery separately. A healthy broker cannot compensate for a broken transaction handler, and more consumers are not helpful if they all retry the same invalid request.<\/p>\n

Secure message payloads and connection identities<\/h2>\n

Avoid embedding secrets or sensitive patient data in broadly distributed events when consumers only need a reference. Use scoped managed identities and service-specific roles where supported, private connectivity where required, transport protection and controlled key management. Different subscriptions and teams should have only the publish, receive and manage permissions needed for their role. A user who can send a message should not automatically be allowed to purge a queue or alter its access policy.<\/p>\n

Include observability for dead-letter growth, oldest message age, failed deliveries, stream consumer lag and API gateway rejection patterns. Interpret the signals together: a growing queue can mean consumer throttling, not necessarily producer overload. Operational ownership must be clear when an integration spans an API team, platform team and finance service.<\/p>\n

Test the failure semantics, not just the successful demo<\/h2>\n

Create a synthetic appointment flow with one durable billing command, one fan-out notification and a stream of device events. Interrupt the billing worker after it has written an idempotency record, then let the message become available again. Verify no duplicate billing result. Rewind a telemetry consumer checkpoint in a controlled lab and confirm reports deduplicate appropriately. Submit unauthorized API calls and confirm the gateway and backend deny them as intended.<\/p>\n

An AZ-305 application-integration architecture should identify each message’s role, delivery and ordering requirements, consumer ownership, API trust boundary, retry and replay procedures, and operational cost. The goal is not to deploy Service Bus, Event Grid, Event Hubs and API Management together in every project. It is to select the minimum set of complementary capabilities that keeps the business operation correct under ordinary traffic and partial failure.<\/p>\n","protected":false},"excerpt":{"rendered":"

Choose messaging, streams, event routing and managed API protection from delivery contracts.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,1],"tags":[],"class_list":["post-4508","post","type-post","status-publish","format-standard","hentry","category-devops-automation","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/4508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/comments?post=4508"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/4508\/revisions"}],"predecessor-version":[{"id":4520,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/4508\/revisions\/4520"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/media?parent=4508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/categories?post=4508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/tags?post=4508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}