Back to template

Sequence Diagram Examples

These sequence diagram examples cover the system interactions developers document most often: authentication, payment flows, async messaging, and third-party API integrations. Each one shows the message order and direction so you can adapt it to your own stack.

Use this templateBack to template
Sequence Diagram Examples

Real examples

JWT authentication flow

Who uses it: Backend developer designing or documenting an auth system

Client → API Gateway: POST /login {email, password}
API Gateway → Auth Service: validate credentials
Auth Service → User DB: SELECT user WHERE email
User DB → Auth Service: user row
Auth Service → Auth Service: bcrypt compare
Auth Service → API Gateway: {access_token, refresh_token}
API Gateway → Client: 200 OK {tokens}

Why this works: Showing the bcrypt compare as a self-call on the Auth Service lifeline makes it clear that password verification happens inside the service, not at the database — a common misconception when onboarding new engineers.

E-commerce checkout flow

Who uses it: Backend or full-stack developer designing a payment integration

User → Frontend: click Place Order
Frontend → Order Service: POST /orders
Order Service → Inventory Service: reserve items
Inventory Service → Order Service: reservation confirmed
Order Service → Payment Gateway: charge card
Payment Gateway → Order Service: payment success
Order Service → Notification Service: send confirmation email
Order Service → Frontend: order created

Why this works: The sequence diagram makes it clear that inventory reservation must happen before payment — reversing the order would result in charging a card for items that may be out of stock.

OAuth 2.0 authorization code flow

Who uses it: Developer integrating a third-party OAuth provider

User → App: click Login with Google
App → Browser: redirect to Google /authorize
Browser → Google: authorization request
Google → Browser: login and consent page
User → Google: approves scope
Google → App: redirect with code
App → Google: POST /token {code, client_secret}
Google → App: access_token + id_token

Why this works: OAuth flows are notoriously confusing because they involve three parties and a redirect dance — the sequence diagram is the only format that shows the redirect chain clearly without losing the reader.

WebSocket real-time chat

Who uses it: Developer building a real-time messaging feature

Client A → Server: WebSocket connect
Client B → Server: WebSocket connect
Client A → Server: send message {room, text}
Server → Server: store message in DB
Server → Client A: message delivered
Server → Client B: new message event
Client B → Client B: render message

Why this works: The server fan-out to multiple clients is the key pattern in real-time messaging — showing it as two separate arrows from the server makes the broadcast behavior explicit.

Microservices event-driven flow

Who uses it: Backend engineer designing an event-driven architecture

Order Service → Message Broker: publish OrderPlaced event
Message Broker → Inventory Service: deliver OrderPlaced
Inventory Service → Inventory Service: decrement stock
Inventory Service → Message Broker: publish StockUpdated
Message Broker → Analytics Service: deliver StockUpdated
Message Broker → Warehouse Service: deliver StockUpdated

Why this works: Event-driven flows are hard to explain in prose — the sequence diagram shows which services are consumers of which events without implying direct synchronous coupling between them.

Password reset flow

Who uses it: Developer implementing or documenting a password reset feature

User → App: click Forgot Password
App → Auth Service: POST /password-reset {email}
Auth Service → DB: create reset token, set expiry
Auth Service → Email Service: send reset link
Email Service → User: email with link
User → App: click link → GET /reset?token=xxx
App → Auth Service: verify token, update password
Auth Service → App: success

Why this works: Including the token expiry step in the sequence diagram reminds the team to implement it — without the diagram, expiry is the most commonly forgotten security requirement in password reset implementations.

Tips for better study mind maps

  • Keep participant names short — use service names or roles, not full class names, so the diagram fits on one screen.
  • Show error and failure paths as separate arrows with a different style or label; happy-path-only diagrams are incomplete specifications.
  • Use return arrows even for async calls so readers know where the response goes — an arrow that goes out and never comes back suggests fire-and-forget, which should be intentional.
  • Number messages sequentially if the order is non-obvious; readers follow numbered steps faster than they trace arrow paths across wide diagrams.

Start editing online

Go back to the template, swap in your own topics, and keep the same structure if it fits your class or project.

Use this template: /editor/new?template=sequence-diagram

Use this template