Skip to article
Integration Azure Service Bus

Receive and delete

Receive and delete is an Azure Service Bus receive mode where the broker considers a message settled as soon as it sends the message to the receiver. If transfer or processing fails afterward, the message is lost instead of being redelivered.

Source: Microsoft Learn - Message transfers, locks, and settlement in Azure Service Bus Reviewed 2026-05-21

Exam trap
Using receive and delete for payment, order, workflow, or compliance messages that require provable processing.
Production check
Review consumer code or configuration and confirm whether the receiver uses receive-and-delete or peek-lock mode.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
ReceiveAndDelete, receive-and-delete mode, destructive read, at-most-once receive
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-21
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Receive and delete is the fast but risky way to read messages from Azure Service Bus. When the receiver gets a message, Service Bus immediately treats it as consumed and removes it from the queue or subscription. If the app crashes, loses the network, or fails to process the payload, that message is gone. This mode can be reasonable for telemetry, sampling, or duplicate-tolerant work where losing an occasional message is acceptable. It is a bad fit for payments, orders, medical records, or anything that requires guaranteed processing.

Why it matters

Receive and delete matters because it is one of those small configuration choices that changes the meaning of a whole messaging workflow. Teams sometimes choose it for speed and simplicity, then discover during an outage that failed consumers silently lost messages. In the right workload, that tradeoff is acceptable: metrics samples, transient notifications, duplicate-tolerant cache refreshes, or data that can be recomputed. In the wrong workload, it destroys auditability and business trust. Architects need to name the expected delivery guarantee, document why message loss is tolerable, and make sure operators do not troubleshoot missing messages as if Service Bus will redeliver them.

Technical context

In Azure architecture, receive and delete is a Service Bus client receive mode in the messaging data plane. It contrasts with peek-lock, where messages are locked, processed, and explicitly completed later. Receive and delete reduces settlement overhead because the broker marks the message settled when it is delivered to the client. The surrounding architecture still includes namespaces, queues, topics, subscriptions, authorization, private endpoints, diagnostics, dead-letter handling for other flows, and application retry logic. The important design point is delivery semantics: this mode is at-most-once, not at-least-once.

Exam context

Compare with

Peek-lock Message lock Dead-letter queue

Where it is used

Where you see it

  1. Service Bus SDK or REST client code sets the receive mode when creating a receiver for a queue, topic subscription, or dead-letter path in application configuration.
  2. Azure Monitor metrics show outgoing messages and falling active counts, while application logs may reveal crashes after messages were already consumed during incident investigation and recovery.
  3. Architecture diagrams, runbooks, and incident notes mention at-most-once delivery when teams document why missing messages will not be redelivered after consumer failure or restart.

Common situations

  • Consume disposable telemetry samples where losing a few messages is acceptable and lower settlement overhead is valuable.
  • Read cache-refresh hints that can be regenerated from a database or another durable event source.
  • Drain noncritical test queues quickly during development without writing completion or dead-letter handling code.
  • Handle duplicate-tolerant notifications where the source system remains authoritative and users can request a refresh.
  • Simplify high-volume monitoring consumers that already keep durable evidence outside Service Bus.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Gaming analytics team accepts loss for live heat-map samples Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A multiplayer gaming studio collected high-volume position samples to update live arena heat maps. The data was useful for trend visualization but not required for billing, ranking, or player entitlements.

Goals
  • Keep heat-map consumers simple during tournament traffic spikes.
  • Avoid lock-renewal and completion overhead for disposable samples.
  • Preserve authoritative gameplay records in a separate event store.
  • Detect consumer crashes quickly enough to restart dashboards.
Approach using Receive and delete

The analytics team used Azure Service Bus for short-lived heat-map sample messages and configured the consumer SDK to use receive and delete. They documented the at-most-once delivery model because losing a small percentage of samples did not affect official match records. Authoritative gameplay events continued flowing to a durable event store. Azure CLI and Azure Monitor tracked queue depth, outgoing messages, and consumer host health, while the dashboard service kept a rolling aggregation rather than relying on every sample. When a dashboard worker crashed, operators restarted it and compared Service Bus metrics with the durable event store to estimate visualization gaps.

Potential outcomes
  • Dashboard latency stayed under one second during the tournament peak.
  • Consumer code avoided lock-renewal complexity for 40,000 messages per minute.
  • Lost samples affected heat-map smoothness but not official match outcomes.
  • Operators detected worker crashes within three minutes through metrics and host alerts.
What to learn

Receive and delete is defensible when messages are disposable hints and the authoritative business record lives somewhere else.

Scenario 02 Smart-building platform drains cache refresh hints Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A smart-building vendor sent cache refresh hints whenever tenant configuration changed. If a hint was lost, services could still refresh from the central configuration database on a timer.

Goals
  • Reduce queue-processing complexity for noncritical refresh hints.
  • Avoid duplicate cache invalidation storms during large tenant migrations.
  • Keep configuration truth in the database, not in the message.
  • Monitor whether lost hints caused stale cache complaints.
Approach using Receive and delete

The platform team used receive and delete for the Service Bus queue carrying cache refresh hints. The message told a service which tenant might need refresh, but the full configuration remained in Azure SQL Database. Each service also performed periodic reconciliation, so a lost hint delayed refresh but did not lose data. The team documented the delivery semantics in the architecture decision record and limited receive access to managed identities for the cache services. Azure CLI inventory checks confirmed queue settings, authorization rules, and diagnostic exports. Application logs recorded when a cache actually refreshed, giving operators evidence separate from Service Bus settlement.

Potential outcomes
  • Cache service code became smaller because it no longer handled lock completion or dead-letter replay.
  • Large migrations produced 22 percent fewer duplicate refresh operations.
  • Stale-cache incidents remained below the agreed service objective.
  • Security review accepted the mode because the database remained the durable source of truth.
What to learn

Receive and delete can simplify hint-based messaging when reconciliation exists and the message is not the system of record.

Scenario 03 Media monitoring service separates alerts from audit records Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A media monitoring company sent noncritical preview alerts to analysts when public broadcasts mentioned client brands. Analysts needed fast heads-up notifications, while compliance evidence was stored elsewhere.

Goals
  • Deliver preview alerts quickly without complex retry handling.
  • Keep authoritative transcript and detection evidence in a durable archive.
  • Prevent shared analyst tools from draining production alert queues.
  • Estimate notification loss after client application outages.
Approach using Receive and delete

The engineering team used receive and delete for a Service Bus subscription consumed by the analyst preview application. The application displayed fast notifications, but official transcripts, timestamps, and detection scores were stored in Blob Storage and Azure Data Explorer. The team rejected receive and delete for compliance exports, which used peek-lock and explicit completion instead. Access to the preview subscription was limited to one managed identity, and Azure Monitor exported message-rate metrics. During an outage in the preview application, operators used archive records and outgoing message metrics to estimate which alerts analysts might have missed, then replayed important summaries from the durable store.

Potential outcomes
  • Analysts received most preview alerts within 500 milliseconds of detection.
  • Compliance exports kept full delivery evidence through a separate peek-lock workflow.
  • A shared test tool was blocked from receiving production preview messages.
  • Outage review identified missed previews without claiming Service Bus would redeliver them.
What to learn

At-most-once delivery can serve fast preview experiences when audit-grade processing is isolated in a stronger messaging path.

Azure CLI

Use Azure CLI for receive and delete indirectly, because Azure CLI is not the normal tool for receiving application messages. The receive mode is usually selected in SDK code or REST calls. CLI still matters to an Azure engineer because it verifies the queues, topics, subscriptions, access policies, diagnostics, private endpoints, and message counts around that code. When a team claims messages disappeared, CLI helps confirm whether the entity is healthy, whether consumers are connected, and whether logs exist. It also provides repeatable inventory for governance: which messaging resources are used by workloads that intentionally accept at-most-once delivery. and governance reviews.

Useful for

  • Inspect queue or subscription properties before reviewing code that uses receive-and-delete mode.
  • Check active message counts and dead-letter counts when operators report missing messages.
  • Inventory authorization rules and role assignments that allow consumers to receive and permanently drain messages.
  • Verify diagnostic settings so message-rate and consumer-failure investigations have enough evidence.
  • Compare Service Bus entities across environments when a workload behaves as at-most-once in one place and peek-lock in another.

Before you run a command

  • Confirm tenant, subscription, resource group, namespace, queue or topic, subscription name, and whether the investigation targets main or dead-letter messages.
  • Remember that Azure CLI generally inspects Service Bus resources; the receive mode is usually in SDK or REST client code.
  • Use read-only show and list commands before changing access policies, diagnostics, or queue settings in production.
  • Check whether the workload uses SAS policies, Microsoft Entra roles, private endpoints, and diagnostic logs before blaming delivery semantics.
  • Capture output as JSON so message counts, entity IDs, authorization rules, and timestamps can be compared with application logs.

What the output tells you

  • activeMessageCount shows how many messages remain available, but receive-and-delete consumers may reduce this without successful processing evidence.
  • deadLetterMessageCount may stay low because lost receive-and-delete messages are settled, not abandoned and redelivered until dead-lettered.
  • authorization rules and role assignments identify which applications or identities can receive and drain messages from the entity.
  • diagnostic settings show whether Service Bus activity and metrics are exported for incident investigation and audit review.
  • entity status, lock duration, and max delivery count still matter for other consumers, even though receive-and-delete bypasses lock completion.

Mapped commands

Service Bus entity inspection

adjacent 
az servicebus queue show --namespace-name <namespace> --resource-group <resource-group> --name <queue-name>
az servicebus queuediscoverIntegration
read-only Microsoft Learn 
az servicebus topic subscription show --namespace-name <namespace> --resource-group <resource-group> --topic-name <topic-name> --name <subscription-name>
az servicebus topic subscriptiondiscoverIntegration
read-only Microsoft Learn 
az servicebus queue authorization-rule list --namespace-name <namespace> --resource-group <resource-group> --queue-name <queue-name>
az servicebus queue authorization-rulediscoverIntegration
read-only Microsoft Learn 
az monitor diagnostic-settings list --resource <service-bus-entity-resource-id>
az monitor diagnostic-settingsdiscoverIntegration
read-only Microsoft Learn 
az servicebus namespace show --name <namespace> --resource-group <resource-group>
az servicebus namespacediscoverIntegration
read-only Microsoft Learn

Architecture context

A seasoned Azure architect treats receive and delete as an explicit business risk decision. It belongs only where losing a message is cheaper than coordinating locks, retries, and duplicate handling. The application code must be honest about that; naming the mode in design documents avoids false assumptions about recovery. For critical workflows, peek-lock with completion, abandon, dead-letter, and idempotency is usually the safer default. If receive and delete is used, I want compensating controls: upstream replay sources, sampling math, durable logs, clear monitoring, and owners who accept the loss model. The queue or subscription configuration alone does not tell the whole story; client behavior defines the guarantee.

Security
Security impact is mostly indirect. Receive and delete does not change who can access a Service Bus entity, but it changes the consequences when an authorized consumer reads messages. A compromised or buggy consumer with receive permission can drain messages permanently without completing business work. Access should therefore be scoped carefully with Microsoft Entra roles or SAS policies, and receive rights should not be given broadly. Private endpoints, firewall rules, and diagnostic logs still matter. The main security-adjacent risk is evidence loss: if messages disappear without processing records, investigations may lack proof of what was received, discarded, or mishandled. during reviews.
Cost
Cost impact is indirect. Receive and delete can reduce application complexity and settlement operations compared with more defensive processing, but the savings are usually small beside the potential cost of lost business messages. For high-volume telemetry or sampling, the simpler mode may reduce compute, lock-renewal, and retry overhead. For orders, payments, or workflow commands, one lost message can cost far more than any operational savings. FinOps review should include failure cost, not just Service Bus operation count. Also consider logging: teams may need stronger application-side evidence because the broker will not retain settled messages for later inspection. during design review.
Reliability
Reliability impact is direct and often negative for critical workflows. Receive and delete provides at-most-once delivery: once Service Bus sends the message, the broker does not redeliver it if processing fails. That can improve simplicity and avoid lock renewal problems, but it removes a major recovery mechanism. Reliable use requires workloads that tolerate loss, have upstream replay, or treat messages as hints rather than records. Operators should monitor consumer crashes, connection drops, and message-rate anomalies because lost messages may not create dead-letter evidence. For business-critical processing, peek-lock with idempotent completion and dead-letter handling is usually the better reliability pattern.
Performance
Performance impact can be positive because receive and delete avoids the extra complete, abandon, lock-renewal, and settlement steps used by peek-lock processing. That can help very high-throughput consumers where each message is disposable or recoverable from another source. The gain comes at the price of weaker recovery. Performance testing should measure end-to-end useful processing, not just faster dequeue rates, because a consumer that drops messages quickly is not performing well for most business workflows. Teams should also watch receiver prefetch settings, batching, network reliability, and application crash behavior, since each delivered message is already considered consumed. during load testing.
Operations
Operators support receive-and-delete workloads by watching entity health, active message counts, incoming and outgoing message rates, consumer errors, and application-side processing records. Troubleshooting requires knowing that missing messages may not appear in the dead-letter queue, because they were settled when delivered. Runbooks should check Service Bus metrics, diagnostic logs, client logs, and upstream replay options. Teams should document which consumers use receive and delete, why loss is acceptable, and how to estimate impact after a crash. Operational reviews should compare this mode against peek-lock when incidents, audit requirements, or business criticality increase. and during post-incident reconciliation and ownership reviews.

Common mistakes

  • Using receive and delete for payment, order, workflow, or compliance messages that require provable processing.
  • Expecting messages to appear in the dead-letter queue after a receive-and-delete consumer crashes mid-processing.
  • Granting broad receive permissions to test tools or shared services that can permanently drain production queues.
  • Measuring success by dequeue speed while ignoring lost work, missing audit records, or downstream processing failures.
  • Forgetting that the receive mode may be hidden in SDK code, not visible as a simple queue property.