User Registration Sequence Diagram — Sign-up Flow Example

Diagram Source — edit it live in the browser

title User Registration Flow

actor User
participant "Web App" as App
participant "Auth Service" as Auth
participant Database
participant "Email Service" as Email

User->App: Fill signup form
App->App: Validate inputs
App->Auth: POST /register
Auth->Database: Check email exists
Database-->Auth: Email not found
Auth->Database: INSERT new user
Auth->Email: Send verification email
Email-->User: Verification link
Auth-->App: 201 Created
App-->User: Check your email

What this diagram shows

This sequence diagram models the standard user sign-up flow for a web application — from form submission through account creation to email verification. It shows the separation of concerns between the web frontend, auth service, database, and email service.

The diagram captures an important security step: the duplicate email check before INSERT. Without this, concurrent registrations could create two accounts with the same email. The check should ideally use a database-level unique constraint as a safety net in addition to the application-level check.

Step-by-step flow breakdown

User fills the signup formName, email, password. The form may have client-side validation (password strength, required fields) before submitting.

Frontend validates inputsThe app validates email format, password complexity rules, and field lengths before making any server call. Self-call notation (App->App) shows internal logic.

POST /register to Auth ServiceValidated form data sent over HTTPS. Password is sent in plain text here but immediately hashed server-side — never stored as-is.

Email uniqueness checkSELECT COUNT(*) FROM users WHERE email = ? confirms no existing account. Returns Email not found = OK to proceed.

New user insertedAuth Service hashes the password (bcrypt/argon2) and inserts the user record with email_verified = false and a verification token.

Verification email sentAuth Service calls the Email Service (SendGrid, SES, Postmark) with the verification link. This is typically done asynchronously or via a queue to avoid blocking the response.

201 Created returnedThe app confirms account creation and tells the user to check their email — they won't be able to log in until they verify.

When to use a registration sequence diagram

Auth implementation docs — show the exact flow, including the email check and hash steps, to other developers
Security review — identify where passwords are handled and confirm they're hashed before storage
Email deliverability debugging — trace the point where verification emails are triggered to find where they're dropping
GDPR compliance docs — document where user data is first stored and what consent is captured

Common variations

Duplicate email — error branch

Add an alt fragment: [email found] returning 409 Conflict: email already registered and [email not found] running the rest of the happy path.

Phone/SMS verification instead of email

Replace the Email Service with an SMS Service (Twilio, SNS). Send a 6-digit OTP rather than a link. Add a second step where the user submits the OTP to verify their number.

Invite-only registration

Add a step before form submission: Auth->Database: Validate invite token. Only users with a valid invite token can create an account.

Social sign-up (OAuth)

Skip the password and email verification steps. See the OAuth 2.0 diagram for the flow when signing up via Google or GitHub.

Related sequence diagram examples

Frequently asked questions

What should a user registration sequence diagram include?

At minimum: form submission, server-side validation, duplicate email check, database insert with hashed password, verification email dispatch, and the response to the user. Include error branches (alt fragments) for duplicate email and validation failures.

Should passwords be hashed before or after the database insert?

Hashing happens in the Auth Service before the INSERT — the plaintext password is hashed immediately on receipt and only the hash is stored. The diagram shows this as a self-call or implicit step within the Auth Service participant.

Why send a verification email — can users log in immediately?

Email verification confirms the user owns the address and prevents someone from registering with another person's email. Most apps create the account immediately but restrict access (or certain features) until the email is verified.

Can I edit this registration diagram?

Yes — click Open in Editor. Add error branches, SMS verification, invite-token validation, or any other step your app has. Export as PNG, SVG, or Mermaid. Free, no account required.

User Registration / Sign-up Sequence Diagram