When do you use a UML sequence diagram?

Direct answer

What a strong answer covers

How it works

A sequence diagram shows one scenario as messages between participants ordered in time from top to bottom, which makes it the right tool when the question is who calls whom, in what order, and what happens on the alternative paths. It exposes synchronous waits, asynchronous messages, timeouts, retries, and the point where responsibility crosses a system boundary, all of which text descriptions tend to blur. It is not for showing structure, data models, or every possible path at once; one diagram per meaningful scenario, including the main failure cases, keeps it readable.

Example

For an online payment, the diagram shows the browser posting to the checkout service, the synchronous call to the payment provider with a 10-second timeout, the alternative fragment for a declined card, and the asynchronous webhook that later confirms settlement. Drawing it surfaced that the order was being marked paid before the webhook arrived, which the written spec had not made obvious.

Common mistakes

• Putting every branch into one diagram until it no longer fits a screen.
• Using it to describe static structure that a component or class diagram shows better.
• Leaving out timeouts and failure alternatives, which are usually the reason the diagram was needed.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.