Sequence diagrams in LLD - System Design Exercise

Design: Sequence Diagram for User Login Flow

Focus on the login process only, excluding registration or password reset flows

Functional Requirements

FR1: Show the interaction between user, frontend, backend, and database during login

FR2: Include authentication and error handling steps

FR3: Demonstrate synchronous and asynchronous message flows

Non-Functional Requirements

NFR1: Diagram must be clear and easy to understand for beginners

NFR2: Must represent real-world request-response timing

NFR3: Should cover up to 10 steps in the sequence

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

User interface (frontend)

Backend authentication service

Database for user credentials

Session or token management

Design Patterns

Request-response pattern

Error handling in sequence diagrams

Synchronous vs asynchronous messages

Activation bars to show processing time

Reference Architecture

User          Frontend          Backend          Database
  |               |                |                 |
  |---Login Req-->|                |                 |
  |               |---Auth Req---->|                 |
  |               |                |---Query User--->|
  |               |                |<--User Data-----|
  |               |<--Auth Resp----|                 |
  |<--Login Resp--|                |                 |
  |               |                |                 |

Components

User

Human interaction

Initiates login request

Frontend

Web or mobile client

Sends login request and displays response

Backend

Authentication server

Processes login, verifies credentials

Database

Relational or NoSQL DB

Stores user credentials and data

Request Flow

1. User enters credentials and sends login request to Frontend

2. Frontend forwards authentication request to Backend

3. Backend queries Database for user data

4. Database returns user data to Backend

5. Backend verifies password and authentication rules

6. Backend sends authentication result back to Frontend

7. Frontend displays login success or failure to User

Database Schema

Entities: - User(id PK, username, password_hash, salt, email) Relationships: - None needed for login flow Notes: - Password stored securely as hash with salt - User table supports authentication queries

Scaling Discussion

Bottlenecks

Backend authentication server CPU limits under high login volume

Database read latency for user credential queries

Frontend handling many simultaneous login requests

Solutions

Use load balancer and multiple backend instances for horizontal scaling

Cache user credentials or session tokens in memory (e.g., Redis) to reduce DB hits

Implement rate limiting and throttling on frontend and backend to prevent overload

Interview Tips

Time: Spend 10 minutes clarifying requirements and participants, 20 minutes drawing and explaining the sequence diagram, 15 minutes discussing scaling and error handling

Clearly identify all actors and their roles

Explain synchronous vs asynchronous messages in the flow

Highlight error handling and alternative flows

Discuss how the design supports scalability and reliability

Practice

1. What is the main purpose of a sequence diagram in system design?

easy

A. To list all system hardware requirements

B. To display database table structures

C. To show how components interact over time

D. To describe user interface colors

Solution

1. Step 1: Understand sequence diagram focus

   Sequence diagrams illustrate the order and flow of messages between system parts over time.

2. Step 2: Compare options with purpose

   Only To show how components interact over time matches this purpose; others describe unrelated system aspects.

3. Final Answer:

   To show how components interact over time -> Option C

4. Quick Check:

   Sequence diagram = interaction over time [OK]

Hint: Sequence diagrams show message flow over time [OK]

Common Mistakes:

• Confusing sequence diagrams with database schemas
• Thinking sequence diagrams show UI design
• Assuming sequence diagrams list hardware

2. Which of the following is the correct syntax to represent a message from Client to Server in a sequence diagram?

easy

A. Client == Server: Request

B. Client <-> Server: Request

C. Client -- Server: Request

D. Client -> Server: Request

Solution

1. Step 1: Identify standard message arrow

   In sequence diagrams, a solid arrow (->) shows a message sent from one object to another.

2. Step 2: Match options to syntax

   Client -> Server: Request uses '->' correctly; others use incorrect or non-standard symbols.

3. Final Answer:

   Client -> Server: Request -> Option D

4. Quick Check:

   Message arrow = '->' [OK]

Hint: Use '->' for messages in sequence diagrams [OK]

Common Mistakes:

• Using double arrows '<->' which imply bidirectional but not standard
• Using dashes '--' which are not message arrows
• Using '==' which is not a valid arrow

3. Given this sequence diagram snippet:

Client -> Server: LoginRequest
Server -> DB: QueryUser
DB -> Server: UserData
Server -> Client: LoginResponse

What is the correct order of messages received by the Server?

medium

A. LoginRequest, UserData

B. UserData, LoginRequest

C. LoginRequest, LoginResponse

D. QueryUser, LoginRequest

Solution

1. Step 1: Identify messages sent to Server

   Server receives 'LoginRequest' from Client and 'UserData' from DB.

2. Step 2: Determine order of reception

   First, Server gets 'LoginRequest', then after querying DB, it receives 'UserData'.

3. Final Answer:

   LoginRequest, UserData -> Option A

4. Quick Check:

   Server messages received = LoginRequest then UserData [OK]

Hint: Trace arrows pointing to Server in order [OK]

Common Mistakes:

• Confusing messages sent by Server with received messages
• Mixing order of messages
• Including messages Server sends as received

4. In this sequence diagram, the message arrow is drawn as Server --> Client: Response. What is the likely issue?

medium

A. The arrow should be solid '->' not dashed '-->'

B. The message label 'Response' is missing

C. The direction of arrow is reversed

D. The lifeline for Client is missing

Solution

1. Step 1: Check arrow style correctness

   Sequence diagrams use solid arrows '->' for messages; dashed arrows '-->' usually represent return messages or asynchronous calls.

2. Step 2: Identify problem in given arrow

   The arrow is dashed '-->' but labeled as a normal message, which is incorrect syntax.

3. Final Answer:

   The arrow should be solid '->' not dashed '-->' -> Option A

4. Quick Check:

   Message arrow must be solid '->' [OK]

Hint: Use solid arrow '->' for normal messages [OK]

Common Mistakes:

• Confusing dashed arrows with normal message arrows
• Ignoring arrow direction
• Assuming label absence is the issue

5. You want to model a system where a Client sends a request to Server, which then calls two services ServiceA and ServiceB in parallel before responding. How should the sequence diagram represent the parallel calls?

hard

A. Use a loop fragment around calls to ServiceA and ServiceB

B. Use combined fragments with 'par' to show parallel calls to ServiceA and ServiceB

C. Draw sequential arrows to ServiceA then ServiceB without any special notation

D. Show only one service call to simplify the diagram

Solution

1. Step 1: Understand parallel calls in sequence diagrams

   Parallel interactions are shown using combined fragments labeled 'par' to indicate concurrent execution.

2. Step 2: Match options to parallel representation

   Use combined fragments with 'par' to show parallel calls to ServiceA and ServiceB correctly uses 'par' fragment; others either show sequential calls or omit parallelism.

3. Final Answer:

   Use combined fragments with 'par' to show parallel calls to ServiceA and ServiceB -> Option B

4. Quick Check:

   Parallel calls = 'par' combined fragment [OK]

Hint: Use 'par' fragment for parallel calls in sequence diagrams [OK]

Common Mistakes:

• Drawing parallel calls as sequential arrows
• Using loop fragments instead of parallel
• Omitting one service call to simplify