Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

ConceptChapter II · Distribution · Building block 3 of 6

Delivery guarantees

A broker can re-deliver a message if there is no confirmation. Reliable processing therefore combines lasting effect with repeatable treatment.

By Michael Meierhoff · Meierhoff Systems

  1. At-most-onceAcknowledgement before storing.
  2. At-least-onceConfirming after storage.
  3. Effectively onceAt-least-once plus idempotency.

Context

Why this is important

The confirmation time decides on loss or duplicate. Exactly-once does not exist as a transport commitment; effectively once arises from at-least-once plus idempotency. Outbox, Idempotence and Retry deepen individual mechanisms.

This building block declares delivery confirmations and re-delivery. Outbox ensures publication from a local transaction; Idempotency protects the effect from duplicates.

At a glance · Acknowledgement after saving

If the acknowledgement fails to arrive, the broker redelivers; processing must therefore be repeatable.
Shop example · Confirmation to play

When is the message acknowledged?

The shop publishes an order for invoicing. A worker stores invoice and order identifier before confirming broker delivery.

This is how you read the picture

  1. At-most-once A crash before saving loses the order.
  2. At-least-once A crash after saving causes redelivery.
  3. Effectively once With ID checking enabled, the result is “effectively once” instead of two invoices.
  1. Broker delivers B-1042
  2. Worker saves invoice
  3. Crash
  4. Worker acknowledgesNot applicable
  5. Broker redelivers
  6. Worker saves invoice (re-)
  7. Worker acknowledges

two invoices

Redelivery of B-1042 reaches a worker without an ID check; it creates a second invoice.

Choose the acknowledgment timing, crash point, and idempotency; the result shows how many invoices B-1042 produces.

Benefits & limitations

Helps if:

  • Delivery guarantees guide design when transport failures can lose or redeliver messages.
  • Separate transport acknowledgement and business changes require handling of the window in which redelivery can occur.
  • An exactly-once guarantee must explicitly state the transaction scope it supports.

Boundaries

  • At-most-once can lose requests; at-least-once can create duplicates. Choose based on the business consequences for invoicing.
  • The broker and invoice store have separate transaction boundaries; a shared identifier is needed to recognise redelivery.
  • Idempotency protects the effect within the worker; Retry also bounds retries and resource consumption.

In practice

  1. Choose the transport guarantees for loss and redelivery and state their transaction boundary. Verify business success separately.
  2. Durably store the recipient’s business effect, then acknowledge the message. A crash between commit and acknowledgement causes redelivery, which the recipient must reliably associate with the existing operation.
  3. Test duplicates and permanent failures, including identifiers and ordering. Idempotency protects effects; Retry controls attempts.
Read the detailed explanation

Delivery guarantees define the outcomes a transport permits: at-most-once avoids repeated delivery but can lose messages; at-least-once retries until acknowledgement and can deliver duplicates.

Exactly-once claims apply only within explicitly supported transaction boundaries. A transport acknowledgement does not automatically mean the business effect is durable. Deduplication, resumption and handling permanent failures close this gap.

Idempotency protects the recipient’s business effect against duplicate delivery; Retry controls the timing and limits of further attempts. Transport acknowledgement and business success remain separate claims.

Exactly-once is not a network transport guarantee. In practice, “effectively once” combines at-least-once delivery with idempotent processing; see Idempotency.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    What result does the “Confirm before saving” view show with a crash between steps?

    View the solution with justification

    “No bill – lost order”: B-1042 is receipted, but the invoice was never stored.

  2. ApplyingTransferred to a new situation

    The shop confirms after saving, the worker crashes in between and does not check an identifier. How many bills are created for B-1042?

    View the solution with justification

    Two. The broker delivers again, and without identification check, the worker creates the invoice a second time.

  3. EvaluateWeighing an alternative

    What speaks for at-least-once with Idempotence instead of at-most-once? What is the price, and what do you recommend for bills?

    View the solution with justification

    Advantage: No order is lost. Disadvantage: The worker needs identification check and filing. For invoices, I recommend at-least-once with Idempotence, because a lost order weighs more technically.

Explore further

These building blocks continue the thoughts of this page.

CommunicationTransactional OutboxTransactional Outbox stores a domain change together with the intent to publish it.Opening CommunicationIdempotencyIdempotence keeps the business effect stable when the same command is repeated.Opening OperationsRetryRetry repeats a failed operation within defined limits and conditions.Opening

References

Continue on the learning path

Next in Distributed systems: CAP & PACELC.

6 Building blocks

Continue withCAP & PACELC