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
Five participants, one sequential dependency chain. The application validates before it calls auth. Auth checks for an existing email before inserting. The password is hashed before the INSERT, not after. Email is sent after the record exists, not before. The sequence matters — and this diagram is faster to read than the controller.
The duplicate email check before INSERT is worth calling out. Concurrent registrations with the same address can sneak past an application-level check if your database doesn't also enforce uniqueness. This diagram surfaces that gap cleanly.
Step-by-step flow breakdown
App->App) shows internal logic.SELECT COUNT(*) FROM users WHERE email = ? confirms no existing account. Returns Email not found = OK to proceed.email_verified = false and a verification token.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.