skip to content

How do a synchronous call, an asynchronous send and a reply differ in a UML sequence diagram?

level: middleimportance: must knowfreq 60%

answer

  1. Filled head, sender waits
  2. Open head, sender carries on
  3. Dashed line means coming back
  4. Reply is implicit for a call
  5. Filled ball marks lost or found

basics

~20 s

A synchronous call is a solid line with a filled arrowhead and the sender waits. An asynchronous send is a solid line with an open stick arrowhead and the sender continues. A reply is a dashed line with an open arrowhead.

solid answer

~50 s

Three forms cover almost every arrow you will draw. A **synchronous call** is a solid line ending in a **filled, solid arrowhead**: the sender's execution suspends until control comes back, which is why its activation bar keeps running across everything the receiver does. An **asynchronous send** is a solid line ending in an **open, stick arrowhead**: the sender hands the message over and carries straight on, so nothing later on its bar depends on the receiver finishing. A **reply** is a **dashed line with an open arrowhead** going back the other way, usually labelled with the returned value. Replies are optional to draw — the end of the receiver's execution bar already implies one for a synchronous call — so teams draw them only where the returned value matters. The line style tells you it is a reply; the arrowhead tells you whether the sender waited.

go deeper

for a junior

Memorise the three arrow shapes and be able to name each on sight: solid line with a filled head, solid line with an open head, dashed line with an open head. Recall which one means the sender waits.

for a middle

Explain what each arrowhead asserts about the sender's own execution bar, why a reply is implicit for a synchronous call, and why drawing a dashed return after an asynchronous send is wrong.

for a senior

Demonstrate judgement about which replies to draw and which to leave implicit so the diagram teaches without clutter, and be able to draw a boundary honestly with lost and found messages.

for a principal

Own the reading conventions across teams: decide whether your diagrams distinguish these forms strictly, since a group that draws every arrow the same way loses the ability to see blocking at a glance.

## The three arrow forms you must recognise on sight Almost every arrow in a sequence diagram is one of three things, and the difference is carried by the **line style** plus the **arrowhead**, not by the label. | Arrow | Line | Arrowhead | Sender does what next | Typical label | | --- | --- | --- | --- | --- | | Synchronous call | Solid | Filled, solid triangle | Suspends until the reply | `reserveSeats(2)` | | Asynchronous send | Solid | Open stick | Continues immediately | `seatsReserved` | | Reply | Dashed | Open stick | n/a — control returns | `: confirmationCode` | | Creation | Dashed | Open stick, into the head | Continues with the new participant | `«create»` | | Destruction | Solid | Filled, ending at a cross | Continues without that participant | `«destroy»` | The two solid forms are the ones people mix up, and the whole distinction is a single visual detail: a **filled** head means the sender blocks; an **open** head means it does not. ## Why the arrowhead matters more than the line The arrowhead is a claim about the **sender**, not about the receiver. A filled head says the sender's execution occurrence continues, unfinished, for as long as the receiver is working — which is why on a well-drawn diagram the caller's activation bar visibly spans the whole nested exchange. An open head says the sender's next event does not wait on anything the receiver does, so the two lifelines are only ordered by the message itself. This has two consequences worth stating out loud in an interview: - An asynchronous send is **not** a promise of concurrency, a thread, or a queue. It says the sender did not wait. How the receiver is scheduled is outside what this notation asserts. - Two asynchronous sends drawn one under the other from the same lifeline are still ordered **relative to each other**, because they share a lifeline. Only their effects on the receivers are unordered relative to the sender's later events. ## Replies, and when to bother drawing them A **reply message** is drawn as a dashed line with an open arrowhead running back from the receiver to the caller, and is conventionally labelled with what comes back — a value, an assignment such as `code := confirm()`, or nothing at all. Drawing replies is optional. For a synchronous call the reply is **implicit**: the end of the receiver's activation bar already marks the return of control, so a diagram that omits the dashed arrow is still correct and is often clearer. Draw the reply when: 1. The returned value is part of what the diagram is teaching. 2. The return happens somewhere non-obvious, such as after the receiver has fired further messages. 3. The reader needs to see that a value flows back at all, because the surrounding arrows are asynchronous. The mirror-image error is drawing a dashed reply after an **asynchronous** send. If the sender never waited, there is no return of control to draw; any answer that comes back later is a new message in its own right, and should be drawn as one. ## Creation, destruction, and the two half-messages Beyond the three main forms, four notations round out the vocabulary: - A **creation message** points at the *head* of a lifeline drawn part-way down the page, stereotyped `«create»`. The created participant has no line above that point. - A **destruction occurrence** ends a lifeline with a large cross. The message that triggers it is often stereotyped `«destroy»`, and nothing may touch that lifeline afterwards. - A **lost message** is an arrow that ends in a small filled ball: it was sent, and the receiver is outside the scope of this diagram or it never arrived. - A **found message** starts from a small filled ball: something arrived, and the sender is outside the scope of this diagram. Lost and found are how you draw an interaction honestly at a boundary, instead of inventing a participant just to have somewhere for an arrow to start. ## The mistakes that cost marks - Calling every solid arrow synchronous, and never noticing the arrowhead fill. - Drawing a dashed reply for an asynchronous send. - Claiming an open arrowhead means "runs on another thread" — it means the sender did not wait, and nothing more. - Drawing a reply as a second solid call, which reads as a fresh request rather than a return. - Sending a message to a lifeline below its destruction cross.

  • If the reply to a synchronous call is implicit, why do teams draw it anyway?
    Because the returned value is often the point of the diagram. An explicit dashed arrow labelled with what comes back tells a reader what the caller now holds, which the end of an activation bar alone does not. It also helps when the return is delayed behind further messages from the receiver. Where the value is irrelevant, omitting the reply removes noise and the diagram stays correct.
  • How would you draw a request whose answer arrives much later, with the sender doing other work meanwhile?
    As two independent asynchronous sends: an open-arrowhead message out, the sender's execution continuing across other messages, and a separate open-arrowhead message back at the point the answer arrives. It is not a reply, because no control was suspended, so it must not be drawn as a dashed return. If the answer's origin is outside the diagram's scope, draw it as a found message from a filled ball.
  • What does an arrow ending in a small filled ball tell a reader?
    That the message is lost: it was sent, and its receiver lies outside this diagram's scope or it never arrived. The mirror form, an arrow starting from a filled ball, is a found message whose sender is out of scope. Both let you draw a boundary honestly rather than inventing a placeholder participant purely to anchor an arrow.

saying these in an interview costs you the question

  • Treats every solid arrow as a synchronous call
  • Draws a dashed reply after an asynchronous send
  • Says an open arrowhead means a separate thread
  • Cannot say what a dashed line signifies
  • Draws a return as a second solid call arrow
  • Sends a message to a lifeline after its destruction cross