Sequence diagrams in LLD - Scalability & System Analysis

Scalability Analysis - Sequence diagrams

Growth Table: Sequence Diagrams at Different Scales

Users	Diagram Complexity	Tools & Performance	Collaboration	Storage & Versioning
100 users	Simple diagrams with few lifelines and messages	Basic tools (e.g., draw.io, PlantUML) work smoothly	Single author or small team editing	Local files or simple cloud storage
10,000 users	Moderate complexity with multiple components and interactions	More powerful tools needed; some lag possible with large diagrams	Multiple collaborators with version control (Git, cloud platforms)	Cloud storage with versioning and backups
1,000,000 users	Very complex diagrams; many lifelines and asynchronous messages	Specialized tools with performance optimization; diagram partitioning	Large teams with strict collaboration workflows and access control	Enterprise-grade storage with audit trails and backups
100,000,000 users	Extremely complex; diagrams split into modules or micro-diagrams	Custom scalable tools; diagram rendering servers; caching layers	Distributed teams with advanced collaboration platforms and automation	Highly scalable storage with redundancy and disaster recovery

First Bottleneck

As the number of users and diagram complexity grow, the first bottleneck is the diagram rendering performance. Large sequence diagrams with many lifelines and messages require significant CPU and memory to render and update in real-time. This slows down user interaction and collaboration.

Scaling Solutions

• Horizontal scaling: Use multiple rendering servers to distribute load for large user bases.
• Diagram partitioning: Split large diagrams into smaller modules or views to reduce rendering complexity.
• Caching: Cache rendered images or partial diagrams to speed up repeated views.
• Collaboration tools: Implement real-time syncing with conflict resolution to support many users editing simultaneously.
• Storage scaling: Use cloud storage with version control and backups to handle large numbers of diagram versions.

Back-of-Envelope Cost Analysis

• Assuming 10,000 active users editing diagrams, each sending ~1 request per second -> 10,000 requests/sec.
• Rendering a complex diagram may take ~100ms CPU time; need ~1000 CPU cores distributed to handle load smoothly.
• Storage: Each diagram version ~500KB; with 10 versions per user -> 5GB storage per 10,000 users.
• Bandwidth: Assuming 100KB per rendered diagram image sent to client, 10,000 users -> ~1GB/s bandwidth needed.

Interview Tip

When discussing scalability for sequence diagrams, start by identifying the main challenges: rendering performance, collaboration, and storage. Then explain how complexity grows with users and diagram size. Propose targeted solutions like partitioning diagrams, caching, and horizontal scaling. Always justify why each solution fits the bottleneck.

Self Check

Your diagram rendering server handles 1000 requests per second. Traffic grows 10x to 10,000 requests per second. What do you do first?

Answer: Add more rendering servers and implement load balancing to distribute the rendering workload horizontally. This prevents CPU bottlenecks and maintains responsiveness.

Key Result

Sequence diagrams scale well up to moderate complexity and users with basic tools, but rendering performance becomes the first bottleneck at large scale. Partitioning diagrams and horizontal scaling of rendering servers are key to handle millions of users smoothly.

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