User, Group, Expense classes in LLD - System Design Exercise

Design: Expense Sharing System

Design the core classes User, Group, and Expense with their relationships and basic methods. Out of scope: UI, payment integration, notifications.

Functional Requirements

FR1: Users can create and join groups.

FR2: Users can add expenses to groups.

FR3: Each expense has a payer and multiple participants.

FR4: The system tracks who owes whom and how much.

FR5: Users can view their balance within each group.

Non-Functional Requirements

NFR1: Support up to 10,000 users and 1,000 groups.

NFR2: Expense addition and balance calculation latency under 200ms.

NFR3: System availability 99.9%.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

User class with user details and group memberships

Group class managing members and expenses

Expense class capturing amount, payer, participants, and splits

Design Patterns

Aggregation pattern for Group containing Users and Expenses

Observer pattern if notifications are needed (out of scope here)

Factory pattern for creating Expense instances with validation

Reference Architecture

User <-- belongs to -- Group <-- contains -- Expense

User:
  - id
  - name
  - groups

Group:
  - id
  - name
  - members (Users)
  - expenses

Expense:
  - id
  - description
  - amount
  - payer (User)
  - participants (Users)
  - splits (map User to amount)

Components

User

Class in any OOP language

Represents a user with identity and group memberships

Group

Class in any OOP language

Represents a group of users sharing expenses

Expense

Class in any OOP language

Represents an expense with payer, participants, and split amounts

Request Flow

1. User creates a Group or joins an existing Group.

2. User adds an Expense to a Group specifying payer, participants, and amount.

3. Group stores the Expense and updates balances for involved Users.

4. Users query Group to get their current balance and owed amounts.

Database Schema

Entities: - User(id PK, name) - Group(id PK, name) - UserGroup(user_id FK, group_id FK) // many-to-many - Expense(id PK, group_id FK, description, amount, payer_id FK) - ExpenseParticipant(expense_id FK, user_id FK, amount) Relationships: - User to Group is many-to-many via UserGroup - Group to Expense is one-to-many - Expense to ExpenseParticipant is one-to-many - ExpenseParticipant links Users to their share in an Expense

Scaling Discussion

Bottlenecks

Calculating balances for large groups with many expenses can be slow.

Storing and querying many-to-many relationships between users and groups.

Handling concurrent expense additions causing race conditions.

Solutions

Cache computed balances per user per group and update incrementally on expense changes.

Use indexed join tables and optimized queries for UserGroup and ExpenseParticipant.

Use transactions or optimistic locking to handle concurrent updates safely.

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for class design and relationships, 10 minutes for scaling and trade-offs discussion.

Clarify assumptions about group membership and expense splitting.

Explain class responsibilities and relationships clearly.

Discuss how to keep balances updated efficiently.

Mention concurrency and data consistency considerations.

Show awareness of scaling challenges and solutions.