An order is accepted, but the warehouse system is briefly unavailable. If the application requires every downstream component to respond immediately, a temporary problem can interrupt the entire customer journey. Messaging offers another approach: record the work that needs to happen and let the responsible component process it when it can.
Azure Service Bus can support that communication, but introducing a queue changes the questions the application must answer. Someone needs to know whether work was accepted, whether its business effect happened and what remains unresolved. A dependable messaging design makes those states visible instead of moving uncertainty out of the web request and into an unobserved background process.
Describe the message as a business contract
Choose whether the message requests an action or reports a fact that has already occurred. “Reserve stock” and “Order approved” have different meanings and ownership. The receiving component should not have to infer that distinction from a generic payload containing whatever fields happened to be available.
For a hypothetical distributor, an approved order might trigger fulfilment preparation and a separate customer notification. Record which system owns the authoritative order state and what each consumer is allowed to change. Keep the message focused on the information required for that responsibility.
Include a stable message identity, correlation information and a versioning strategy appropriate to the contract. Avoid sending unnecessary personal or confidential data when a reference and an authorised lookup would be sufficient. Document how a consumer should react to missing information or a contract version it cannot process.
Distinguish broker acceptance from business completion
Service Bus message settlement describes how senders, receivers and the broker acknowledge transfers and processing outcomes. The service documentation explains receive modes, locks and settlement operations. Those transport states need to be mapped to the business workflow rather than presented as interchangeable meanings of success. Message transfers, locks and settlement.
If the broker accepts a request to prepare an order, the application can report that preparation was queued. It should not report that the warehouse finished the work. Define how completion is recorded and how the originating workflow discovers it when that information matters to the user.
Expose unresolved work in an operational view with its age, current state and owner. A customer-service colleague should be able to distinguish a normal processing delay from a failure needing intervention. Technical message counts alone rarely provide enough context for that decision.
Make repeated delivery safe for the operation
A consumer can apply a business change and then fail before its acknowledgement reaches the broker. Design for the possibility that the message is received again. Use a durable operation identity and appropriate transaction boundaries so the same request does not silently create a second shipment or notification obligation.
Define what counts as the same operation. Reusing a message identifier for materially different work can conceal a legitimate update, while generating a fresh identifier for every retry can defeat duplicate protection. Keep the identity connected to the business intent rather than the process attempt.
Test the failure between applying the effect and completing message handling. This is more revealing than a test in which processing fails before anything changes. Verify that a repeated attempt produces the intended final state and an understandable diagnostic trail.
Plan publication and database changes together
Consider the boundary between recording an order and publishing the message about it. If one succeeds and the other fails, the system needs a recovery strategy. Writing an order to SQL Server and sending to a broker are not automatically one atomic transaction merely because they occur in the same application method.
One design to evaluate is a transactional outbox: record the business change and a pending outgoing event in the same local transaction, then publish that event through a separate process. The implementation still needs duplicate handling, monitoring and cleanup. Treat it as a deliberate consistency mechanism, not a decorative architectural label.
For the distributor, reconcile approved orders against fulfilment requests so missing publication can be detected. A well-designed mechanism reduces the likelihood of gaps, while reconciliation provides evidence about actual business completeness when something unexpected occurs.
Give failed messages an owned resolution path
Some failures are temporary; others indicate an invalid request, incompatible contract or missing business decision. Classify them so the system does not keep repeating work that cannot succeed. A queue that continually retries an invalid message can consume resources while delaying attention to the underlying problem.
Service Bus dead-letter queues retain messages that cannot be delivered or processed under the relevant conditions. Microsoft documents how to inspect and work with them. Retention is useful only if a team owns investigation and controlled resolution. Service Bus dead-letter queues.
Create a review process that records the reason, proposed correction and expected effect of replaying work. Before resubmission, check whether any partial business effect already occurred. Avoid bulk replay as the default response to an unexplained backlog, especially for operations that create external obligations.
Operate for business timeliness
Set expectations for how long important work may remain pending. Monitor age and completion outcomes alongside queue depth, and connect alerts to a named response. A small number of old, high-value orders can be more consequential than a large burst of routine work that clears quickly.
Exercise consumer outages, invalid messages and bursts above normal demand. Decide whether ordering is required for a particular business entity and use the appropriate service capability and application rules when it is. Do not assume that all independently processed work will finish in the order it was submitted.
Worktechlabs can help design asynchronous business integrations with clear states and recoverable processing. Pair the broker design with background-job ownership and API contract discipline so the system remains explainable when components operate at different speeds.
Official sources and further reading
- Microsoft: Service Bus message settlement — transfer acknowledgements and receiver behaviour.
- Microsoft: Service Bus dead-letter queues — inspecting and resolving retained failures.
