par starts parallel sections, and separates them and end closes the block. It is drawn as a frame whose sections happen at the same time.

What about lost or duplicated messages?

Publisher confirms, consumer acknowledgments and idempotent handling work together. The diagram shows acknowledgment and retry; add idempotency as described above.

Is message order guaranteed?

That depends on the queue type and configuration. When strict order matters, use one partition key or an ordered queue and note it on the diagram; most notification cases do not need it.

Message queue async processing sequence diagram template

Previewed in the “Cinnabar” theme; you can switch themes in the editor

When to use it

Use it to explain why a team uses a message queue, to document an asynchronous path in an architecture proposal, or to prepare for a backend interview. It shows three things: the user gets a response without waiting for downstream work, the two consumers do not affect each other, and failures are retried and end up in a dead-letter queue for a person to handle.

Make it yours

Replace orders, inventory and notifications with your own case, such as sending email after sign-up or transcoding after upload.
To show idempotency, add "Check whether already processed" before each consumer's work.
To make saving the order and publishing succeed together, add an outbox table as a participant.

Mermaid code

message-queue-sequence.mmd

sequenceDiagram
    actor U as User
    participant O as Order service
    participant Q as Message queue
    participant S as Inventory service
    participant N as Notification service
    U->>O: Place order
    O->>O: Save order
    O->>Q: Publish order created
    O-->>U: Return success immediately
    par Inventory consumer
        Q->>S: Deliver message
        S->>S: Reserve stock
        S-->>Q: Acknowledge
    and Notification consumer
        Q->>N: Deliver message
        N->>N: Send email and push
        N-->>Q: Acknowledge
    end
    opt Consumer fails
        S-->>Q: No acknowledgment
        Q->>S: Redeliver with backoff
        Q->>Q: Move to dead-letter queue after max retries
    end

Ask an AI for one with this structure

Send the prompt below to ChatGPT or Claude, then paste the whole reply into the editor; the code inside is detected automatically.

prompt.txt

Draw a message queue asynchronous processing sequence diagram with Mermaid sequenceDiagram syntax. Participants are User, Order service, Message queue, Inventory service and Notification service. The user places an order; the order service saves it, publishes "order created" and returns success immediately. Use par to show the inventory service and the notification service consuming in parallel and acknowledging. Use opt to show a consumer failing: no acknowledgment, redelivery with backoff, and a move to the dead-letter queue after the maximum retries. Output only the mermaid code block.

FAQ

What does par mean?: par starts parallel sections, and separates them and end closes the block. It is drawn as a frame whose sections happen at the same time.
What about lost or duplicated messages?: Publisher confirms, consumer acknowledgments and idempotent handling work together. The diagram shows acknowledgment and retry; add idempotency as described above.
Is message order guaranteed?: That depends on the queue type and configuration. When strict order matters, use one partition key or an ordered queue and note it on the diagram; most notification cases do not need it.

More in this category

All templates

Updated 2026-11-11