Should a notification failure block an order?

The order already exists

Return successful order acceptance with the order number. State honestly that confirmation may arrive later. Failure of an auxiliary email does not change the committed business outcome and should not invite the customer to place the order again.

Retry the right work

Retry notification delivery, not order creation. The notification task must be durable and observable. A simple design can insert a notification_pending record in the same transaction as the order, then let a worker deliver it. With more event types, a transactional outbox is a common implementation. The worker must tolerate retries because at-least-once delivery can produce duplicate attempts.

Saving the order and then making an ordinary queue publish is still a dual write. A failure between the two operations can leave an order without a notification task. An outbox does not guarantee exactly one email; it preserves the intent to send and still requires an idempotent consumer or deduplication.

How to verify it

Simulate mail unavailability and terminate the process immediately after the order commit. There should be one order and one durable notification task, the API should return the order number, and delivery should resume without creating another order. If notification were a legal condition of acceptance, the contract would be different — but that is not this scenario.