Use case diagrams in LLD - Scalability & System Analysis

Scalability Analysis - Use case diagrams

Growth Table: Use Case Diagrams

Users/Projects	What Changes
100 users	Simple diagrams with few actors and use cases. Mostly manual drawing or small tools.
10K users	Need for collaborative tools, version control, and reuse of diagram components. Performance starts to matter.
1M users	Cloud-based platforms with multi-tenant support, real-time collaboration, and integration with other design tools.
100M users	Global distributed systems, heavy caching, AI-assisted diagram generation, and advanced analytics on usage patterns.

First Bottleneck

At small scale, the bottleneck is usually the tool's ability to handle multiple actors and use cases without clutter. As users grow, the bottleneck shifts to collaboration and version control systems that manage concurrent edits and diagram history. At very large scale, the bottleneck becomes the backend infrastructure supporting real-time updates and data synchronization across many users.

Scaling Solutions

• Small scale: Use simple desktop tools or lightweight web apps.
• Medium scale: Implement collaboration features with locking or operational transformation to handle concurrent edits.
• Large scale: Use cloud infrastructure with horizontal scaling, real-time databases (like Firebase), and CDN for static assets.
• Very large scale: Employ sharding of user data, caching of frequently accessed diagrams, and AI to assist in diagram creation and error detection.

Cost Analysis

Assuming 10K active users editing diagrams:

• Requests per second: ~167 (assuming 1 edit per user per minute)
• Storage: Each diagram ~100KB, with 10K users and average 5 diagrams each = ~5GB storage
• Bandwidth: Edits and updates ~50KB per request, 167 RPS = ~8.35MB/s (~66.8Mbps)

Scaling to 1M users multiplies these numbers by 100, requiring distributed storage, load balancing, and CDN usage.

Interview Tip

When discussing scalability of use case diagram tools, start by identifying user growth and collaboration needs. Explain how concurrency and data synchronization become challenges. Discuss backend scaling, caching, and real-time update strategies. Always relate solutions to user experience and system responsiveness.

Self Check

Your diagram collaboration backend handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Add read replicas and implement caching to reduce database load. Also, consider horizontal scaling of application servers to handle increased concurrent connections.

Key Result

Use case diagram tools scale from simple single-user apps to complex cloud platforms requiring real-time collaboration and distributed infrastructure as user count grows from hundreds to millions.

Practice

1. What is the primary purpose of a use case diagram in system design?

easy

A. To show user roles and their interactions with the system

B. To display database table relationships

C. To illustrate the internal code structure

D. To list all system hardware components

Solution

1. Step 1: Understand the role of use case diagrams

   Use case diagrams focus on users (actors) and what they do with the system (use cases).

2. Step 2: Compare with other diagram types

   Database diagrams show tables, code diagrams show code structure, hardware diagrams show physical parts, none are use case diagrams.

3. Final Answer:

   To show user roles and their interactions with the system -> Option A

4. Quick Check:

   Use case diagram = user roles + actions [OK]

Hint: Use case = users + actions, not code or hardware [OK]

Common Mistakes:

• Confusing use case diagrams with class or sequence diagrams
• Thinking use case diagrams show database details
• Assuming use case diagrams show internal code logic

2. Which of the following is the correct symbol for an actor in a use case diagram?

easy

A. A rectangle with the actor's name inside

B. An oval shape showing a system function

C. A stick figure representing a user

D. A diamond shape indicating a decision

Solution

1. Step 1: Identify actor symbol in use case diagrams

   Actors are shown as stick figures to represent users or external systems.

2. Step 2: Differentiate other symbols

   Ovals represent use cases (functions), rectangles can be system boundaries, diamonds are for decisions in flowcharts, not use case diagrams.

3. Final Answer:

   A stick figure representing a user -> Option C

4. Quick Check:

   Actor symbol = stick figure [OK]

Hint: Actors are stick figures, use cases are ovals [OK]

Common Mistakes:

• Using rectangles for actors instead of stick figures
• Confusing use case ovals with actor symbols
• Mixing flowchart symbols with use case diagram symbols

3. Consider a use case diagram with actors Customer and Admin, and use cases Place Order, Cancel Order, and Update Inventory. Which use case should only be connected to the Admin actor?

medium

A. Place Order

B. Cancel Order

C. Place Order and Cancel Order

D. Update Inventory

Solution

1. Step 1: Analyze actor responsibilities

   Customers place and cancel orders; Admin manages inventory updates.

2. Step 2: Match use cases to actors

   Only Admin should connect to Update Inventory as it is a system management task.

3. Final Answer:

   Update Inventory -> Option D

4. Quick Check:

   Admin-only use case = Update Inventory [OK]

Hint: Admin manages system tasks, customers do orders [OK]

Common Mistakes:

• Connecting customers to inventory updates
• Assuming customers can update system data
• Linking all use cases to all actors

4. A use case diagram shows an actor connected to a use case with a dashed arrow labeled <<extend>>. What does this indicate?

medium

A. The extended use case adds optional behavior to the base use case

B. The actor is not allowed to perform the extended use case

C. The actor must always perform the extended use case

D. The use case is a system boundary

Solution

1. Step 1: Understand <<extend>> relationship

   The <<extend>> arrow shows optional or conditional behavior added to a base use case.

2. Step 2: Interpret actor connection meaning

   The actor can perform the base use case; the extended use case happens only sometimes.

3. Final Answer:

   The extended use case adds optional behavior to the base use case -> Option A

4. Quick Check:

   <<extend>> = optional behavior [OK]

Hint: <<extend>> means optional addition, not mandatory [OK]

Common Mistakes:

• Thinking <<extend>> means mandatory action
• Confusing <<extend>> with <<include>>
• Assuming <<extend>> defines system boundaries

5. You are designing a use case diagram for an online library system. Which of the following best represents a correct use case for the Member actor that includes an Admin actor managing the system?

hard

A. Member: Add Book, Remove Book; Admin: Borrow Book, Return Book

B. Member: Borrow Book, Return Book; Admin: Add Book, Remove Book

C. Member: Borrow Book, Add Book; Admin: Remove Book, Return Book

D. Member: Remove Book, Return Book; Admin: Borrow Book, Add Book

Solution

1. Step 1: Identify typical member actions

   Members usually borrow and return books, not manage inventory.

2. Step 2: Identify admin responsibilities

   Admins add or remove books to keep the library updated.

3. Step 3: Match actions to actors correctly

   Member: Borrow Book, Return Book; Admin: Add Book, Remove Book correctly assigns borrowing and returning to Member, and adding/removing to Admin.

4. Final Answer:

   Member: Borrow Book, Return Book; Admin: Add Book, Remove Book -> Option B

5. Quick Check:

   Member = borrow/return, Admin = add/remove [OK]

Hint: Members use books; Admins manage books [OK]

Common Mistakes:

• Swapping member and admin roles
• Assigning management tasks to members
• Mixing use cases between actors