Relationships (association, aggregation, composition) in LLD - System Design Exercise

Design: Object Relationship Modeling System

In scope: Modeling and managing object relationships with association, aggregation, and composition. Out of scope: Complex inheritance hierarchies, UI design beyond basic visualization.

Functional Requirements

FR1: Model different types of relationships between objects: association, aggregation, and composition

FR2: Allow creation, update, and deletion of objects and their relationships

FR3: Visualize relationships clearly to distinguish their types

FR4: Support querying objects based on their relationships

Non-Functional Requirements

NFR1: Handle up to 10,000 objects and 50,000 relationships

NFR2: Response time for queries should be under 200ms

NFR3: System availability should be 99.9%

NFR4: Data consistency must be maintained for relationship updates

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Object storage (database or in-memory)

Relationship manager module

API layer for CRUD operations

Visualization component

Query engine

Design Patterns

Composite pattern for composition relationships

Graph data modeling for relationships

Observer pattern if lifecycle events need tracking

Repository pattern for data access abstraction

Reference Architecture

  +-------------------+       +---------------------+
  |   API Layer       |<----->|  Relationship Manager|
  +-------------------+       +---------------------+
           |                            |
           v                            v
  +-------------------+       +---------------------+
  | Object Storage DB  |<----->|  Query Engine       |
  +-------------------+       +---------------------+
                                   |
                                   v
                          +---------------------+
                          | Visualization Layer  |
                          +---------------------+

Components

API Layer

RESTful API or GraphQL

Handles client requests to create, update, delete, and query objects and relationships

Relationship Manager

Backend service in chosen language

Manages logic for association, aggregation, and composition relationships including lifecycle rules

Object Storage DB

Relational DB (e.g., PostgreSQL) or Graph DB (e.g., Neo4j)

Stores objects and their relationships with appropriate schema

Query Engine

Custom query processor or DB query interface

Processes queries on objects and relationships efficiently

Visualization Layer

Frontend library (e.g., D3.js)

Displays objects and their relationships visually, distinguishing relationship types

Request Flow

1. Client sends request to API Layer to create or update an object or relationship

2. API Layer forwards request to Relationship Manager

3. Relationship Manager applies rules based on relationship type (e.g., composition enforces lifecycle dependency)

4. Relationship Manager updates Object Storage DB accordingly

5. For queries, API Layer sends query to Query Engine

6. Query Engine retrieves data from Object Storage DB and returns results

7. Visualization Layer fetches data via API and renders relationship graphs

Database Schema

Entities: - Object: id (PK), name, type, attributes - Relationship: id (PK), source_object_id (FK), target_object_id (FK), type (association, aggregation, composition) Relationships: - Object to Relationship is 1:N (one object can have many relationships) - Relationship links two Objects Composition enforces cascade delete from source to target objects

Scaling Discussion

Bottlenecks

Database performance with large number of objects and relationships

Query latency for complex relationship traversals

Visualization rendering performance for large graphs

Solutions

Use graph databases optimized for relationship queries to improve traversal speed

Implement caching for frequent queries to reduce DB load

Paginate and limit visualization data; use progressive rendering techniques

Partition data or use sharding for very large datasets

Interview Tips

Time: Spend 10 minutes understanding and clarifying requirements, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing

Explain differences between association, aggregation, and composition clearly

Describe how lifecycle dependencies are enforced in composition

Justify choice of database technology based on relationship queries

Discuss how to keep data consistent and performant at scale

Mention visualization challenges and solutions

Practice

1. Which relationship describes two objects connected without ownership, where both can exist independently?

easy

A. Inheritance

B. Association

C. Composition

D. Aggregation

Solution

1. Step 1: Understand relationship types

   Association means objects are linked but do not own each other and can exist separately.

2. Step 2: Compare with other relationships

   Aggregation and composition imply ownership; inheritance is a different concept.

3. Final Answer:

   Association -> Option B

4. Quick Check:

   Association = connected without ownership [OK]

Hint: No ownership means association, not aggregation or composition [OK]

Common Mistakes:

• Confusing aggregation with association
• Thinking composition allows independent existence
• Mixing inheritance with relationships

2. Which of the following correctly shows a composition relationship in UML notation?

easy

A. A solid diamond at the owner end connected to the part

B. A hollow diamond at the owner end connected to the part

C. A plain line with no diamonds between objects

D. A dashed arrow pointing from part to owner

Solution

1. Step 1: Recall UML notation for composition

   Composition uses a solid diamond at the owner end to show strong ownership.

2. Step 2: Differentiate from aggregation and association

   Aggregation uses hollow diamond; association uses plain line; dashed arrow is for dependency.

3. Final Answer:

   A solid diamond at the owner end connected to the part -> Option A

4. Quick Check:

   Composition = solid diamond [OK]

Hint: Solid diamond means composition, hollow means aggregation [OK]

Common Mistakes:

• Mixing hollow and solid diamonds
• Confusing association line with composition
• Using dashed arrows for composition

3. Consider this code snippet representing relationships:

class Engine:
    pass

class Car:
    def __init__(self):
        self.engine = Engine()

What type of relationship does Car have with Engine?

medium

A. Association

B. Aggregation

C. Inheritance

D. Composition

Solution

1. Step 1: Analyze ownership in code

   Car creates and owns Engine instance inside its constructor, implying strong ownership.

2. Step 2: Match with relationship definitions

   Since Engine cannot exist meaningfully without Car here, this is composition.

3. Final Answer:

   Composition -> Option D

4. Quick Check:

   Car owns Engine fully = Composition [OK]

Hint: Creating owned object inside means composition [OK]

Common Mistakes:

• Thinking it's aggregation because of ownership
• Confusing association with composition
• Assuming inheritance from code

4. Identify the error in this aggregation example:

class Wheel:
    pass

class Car:
    def __init__(self, wheels):
        self.wheels = wheels

car = Car([Wheel(), Wheel()])

What is wrong with this aggregation?

medium

A. Wheels cannot exist independently in aggregation

B. Car should not hold wheels as a list

C. No error; this is correct aggregation

D. Wheels should be created inside Car for composition

Solution

1. Step 1: Understand aggregation ownership

   Aggregation means Car owns wheels but wheels can exist independently.

2. Step 2: Check code for ownership and independence

   Wheels are created outside Car and passed in, so they can exist alone, matching aggregation.

3. Final Answer:

   No error; this is correct aggregation -> Option C

4. Quick Check:

   Aggregation allows independent parts [OK]

Hint: Aggregation parts created outside owner, passed in [OK]

Common Mistakes:

• Thinking wheels must be created inside Car
• Confusing aggregation with composition
• Assuming list usage is wrong

5. You are designing a library system where a Library contains many Books. Books can exist outside the library and be moved between libraries. Which relationship best fits this scenario and why?

hard

A. Aggregation, because library owns books but books can exist alone

B. Composition, because books depend fully on the library

C. Association, because library and books are loosely connected

D. Inheritance, because books inherit properties from library

Solution

1. Step 1: Analyze ownership and existence

   Books can exist independently and move between libraries, so they are not fully owned.

2. Step 2: Match relationship type

   Aggregation fits because library owns books but books can exist alone and be shared.

3. Final Answer:

   Aggregation, because library owns books but books can exist alone -> Option A

4. Quick Check:

   Aggregation = ownership with independent parts [OK]

Hint: If parts can exist alone, use aggregation [OK]

Common Mistakes:

• Choosing composition thinking books depend fully
• Selecting association ignoring ownership
• Confusing inheritance with ownership