Skip to content
Software Architecture Guide

Message Types in Sequence Diagrams

Explanation

Section titled “Explanation”

A sequence diagram (see UML Sequence Diagram) shows how parts of a system talk to each other over time. Each arrow is a message.

The most important property of a message is whether the sender waits.

  • Synchronous message: the caller must wait until the message is done.
  • Asynchronous message: the sender can keep processing. It does not wait for a response.

For a deeper look at this difference outside diagrams, see Synchronous vs. Asynchronous Communication.

Why this matters for documentation: arc42 is a template for documenting architecture. Its runtime view describes how building blocks work together in important scenarios. arc42 lists sequence diagrams as one of several notations for these scenarios. It recommends them because they make each participating building block’s responsibility explicit. That helps teams discuss what each building block should do.

When you read an arrow in such a diagram, ask first: does the sender wait here or not?

Example

Section titled “Example”

Imagine a web shop. The checkout part asks the payment part to charge a card. Checkout cannot continue until the charge finishes, so this is a synchronous message. Afterward, checkout tells the email part to send a receipt and moves on without waiting. That is an asynchronous message.

Trade-offs

Section titled “Trade-offs”

A synchronous caller is held up until the work is done. An asynchronous sender can keep processing, but it does not wait for a response.

Checks

Section titled “Checks”
  • Runtime scenarios in the architecture document are shown with sequence diagrams, or another deliberately chosen scenario notation.
  • The sequence diagrams make clear what each participating building block is responsible for.
Section titled “Related”

Sources

Section titled “Sources”