Sequence diagrams in LLD - System Design Guide

Problem Statement

When multiple components or objects interact in a system, it becomes hard to understand the order and flow of messages between them. Without a clear visualization, developers may misinterpret the sequence of operations, leading to bugs and inefficient designs.

Solution

Sequence diagrams show the exact order of messages exchanged between components over time. They represent each participant as a vertical line and messages as horizontal arrows, making it easy to follow the flow of interactions step-by-step.

Architecture

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│   Client    │      │  Server     │      │  Database   │
└──────┬──────┘      └──────┬──────┘      └──────┬──────┘
       │                     │                     │     
       │ 1. Request          │                     │     
       ├────────────────────>│                     │     
       │                     │ 2. Query             │     
       │                     ├────────────────────>│     
       │                     │                     │ 3. Result
       │                     │<────────────────────┤     
       │ 4. Response         │                     │     
       │<────────────────────┤                     │     
       │                     │                     │     

This diagram shows a client sending a request to a server, the server querying a database, and the database returning a result, followed by the server responding back to the client.

Trade-offs

✓ Pros

→

Clearly visualizes the order of interactions between components.

→

Helps identify bottlenecks and unnecessary calls in the flow.

→

Improves communication among team members by providing a common understanding.

→

Useful for both design and debugging phases.

✗ Cons

→

Can become cluttered and hard to read with many participants or complex flows.

→

Does not show internal logic or data transformations within components.

→

Requires maintenance to stay updated as the system evolves.

Use sequence diagrams when designing or documenting interactions in systems with multiple components or services, especially when the order of operations matters and the flow is complex.

Avoid sequence diagrams for very simple systems with few interactions or when the focus is on static structure rather than dynamic behavior.

Real World Examples

Amazon

Amazon uses sequence diagrams to model the order of service calls in their order processing system to ensure correct payment, inventory update, and shipping steps.

Uber

Uber models rider-driver matching flows with sequence diagrams to clarify the message exchanges between mobile apps, dispatch servers, and location services.

Netflix

Netflix uses sequence diagrams to design the interactions between user devices, content delivery networks, and authentication services to optimize streaming startup times.

Code Example

The before code shows function calls without clear order or message flow. The after code adds print statements to simulate the sequence diagram flow, making the interaction order explicit and easier to understand.

LLD

### Before: No clear interaction flow, just function calls without order visualization
class Client:
    def request(self):
        server = Server()
        server.process()

class Server:
    def process(self):
        db = Database()
        db.query()

class Database:
    def query(self):
        print("Querying data")

client = Client()
client.request()


### After: Using sequence diagram concept to clarify flow (pseudo-code with comments)
# Sequence Diagram:
# Client -> Server: request()
# Server -> Database: query()
# Database -> Server: result
# Server -> Client: response

class Client:
    def request(self):
        print("Client sends request to Server")
        server = Server()
        response = server.process()
        print(f"Client receives: {response}")

class Server:
    def process(self):
        print("Server processes request")
        db = Database()
        result = db.query()
        print("Server sends response to Client")
        return result

class Database:
    def query(self):
        print("Database executes query")
        return "data"

client = Client()
client.request()

Alternatives

Flowcharts

Flowcharts focus on decision points and process steps rather than message exchanges between components.

Use when: Choose flowcharts when you need to represent internal logic or decision-making rather than interactions.

Communication diagrams

Communication diagrams emphasize relationships and message links between objects but do not show the time sequence explicitly.

Use when: Use communication diagrams when the focus is on object relationships rather than the order of messages.

Summary

Sequence diagrams visualize the order of messages between system components over time.

They help developers understand and communicate complex interaction flows clearly.

They are best used when the sequence of operations is critical to system behavior.

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