User, Group, Expense classes in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identify the correct relationship between User, Group, and Expense classes

In a system where users can belong to groups and share expenses, which of the following best describes the relationship between User, Group, and Expense classes?

A Users belong to a single Group only; Expenses belong to Users only; Groups do not track Expenses.

B A User can belong to multiple Groups; a Group contains multiple Users; an Expense is linked to a Group and paid by a User.

C An Expense belongs to multiple Users; Groups are independent and do not contain Users; Users pay Expenses individually.

D A Group belongs to a single User; an Expense belongs to a User only; Users do not belong to Groups.

💡 Hint

Think about how users collaborate in groups and how expenses are shared.

Users can be members of multiple groups, groups contain multiple users, and expenses are linked to groups and paid by users.

❓ Architecture

intermediate

Choose the best class attribute to represent an Expense's payer

Which attribute best represents the payer of an Expense in the Expense class?

A payer_group: stores the Group object that paid the expense.

B payer_name: stores the name of the User who paid the expense as a string.

C payer_id: stores the unique identifier of the User who paid the expense.

D payer_amount: stores the amount paid by the User.

💡 Hint

Consider how to uniquely identify the payer without duplicating user data.

Using payer_id links the expense to the User uniquely and avoids data duplication.

❓ scaling

advanced

Scaling the Group class for thousands of Users

When a Group contains thousands of Users and hundreds of Expenses, which design choice helps maintain performance and scalability?

A Store only User IDs in the Group class and fetch User details on demand.

B Store User objects directly inside the Group class as a list.

C Duplicate User data inside each Group to avoid fetching from User class.

D Store Expense objects inside each User instead of the Group.

💡 Hint

Think about memory usage and data duplication when handling large numbers.

Storing only User IDs reduces memory usage and allows lazy loading of User details, improving scalability.

❓ tradeoff

advanced

Tradeoff between storing Expense split details in Expense vs User

Where should the details of how an Expense is split among Users be stored for best design?

A Store split details in a separate Split class linking Users and Expenses.

B Store split details inside each User class as a list of Expenses and amounts.

C Store split details inside the Expense class as a map of User IDs to amounts.

D Do not store split details; calculate splits dynamically each time.

💡 Hint

Consider separation of concerns and flexibility for future changes.

A separate Split class cleanly models the many-to-many relationship and allows flexible queries.

❓ estimation

expert

Estimate storage for 1 million Users, 100k Groups, and 10 million Expenses

Estimate the approximate storage needed if each User object requires 1KB, each Group object 2KB, and each Expense object 0.5KB. Ignore overhead and indexes.

A Approximately 8.5 GB

B Approximately 7.5 GB

C Approximately 5.5 GB

D Approximately 6.5 GB

💡 Hint

Calculate total size by multiplying counts by sizes and summing.

Users: 1,000,000 * 1KB = 1,000,000 KB = ~1GB
Groups: 100,000 * 2KB = 200,000 KB = ~0.2GB
Expenses: 10,000,000 * 0.5KB = 5,000,000 KB = ~5GB
Total ~6.2GB rounded to 6.5GB.

Practice

1. Which class is primarily responsible for storing information about individual people in a shared expense system?

easy

A. Payment

B. User

C. Expense

D. Group

Solution

1. Step 1: Understand the role of each class

   User class represents individual people, Group holds multiple users, Expense tracks costs.

2. Step 2: Identify which class stores individual info

   User class stores personal details like name and ID for each person.

3. Final Answer:

   User -> Option B

4. Quick Check:

   User = Individual person [OK]

Hint: User class = individual person info [OK]

Common Mistakes:

• Confusing Group with User
• Thinking Expense stores user details
• Assuming Payment is a class here

2. Which of the following is the correct way to define a Group class that holds multiple User objects in Python?

easy

A. class Group:
def __init__(self):
self.users = []

B. class Group:
def __init__(self):
self.user = {}

C. class Group:
def __init__(self):
self.expenses = []

D. class Group:
def __init__(self):
self.members = None

Solution

1. Step 1: Identify correct attribute for multiple users

   A list is suitable to hold multiple User objects, so self.users = [] is correct.

2. Step 2: Check other options for correctness

   class Group: def __init__(self): self.user = {} uses a dict named user which is not typical for holding users; class Group: def __init__(self): self.expenses = [] uses expenses which belongs to Expense class; class Group: def __init__(self): self.members = None sets members to None which is not a collection.

3. Final Answer:

   class Group: def __init__(self): self.users = [] -> Option A

4. Quick Check:

   Group holds list of users = self.users = [] [OK]

Hint: Group holds list of users with self.users = [] [OK]

Common Mistakes:

• Using dict instead of list for users
• Confusing expenses with users
• Initializing members as None instead of a list

3. Given the following code snippet, what will be the output?

class Expense:
    def __init__(self, amount, paid_by, split_between):
        self.amount = amount
        self.paid_by = paid_by
        self.split_between = split_between

    def split_amount(self):
        return self.amount / len(self.split_between)

expense = Expense(120, 'Alice', ['Alice', 'Bob', 'Charlie'])
print(expense.split_amount())

medium

A. Error

B. 60

C. 120

D. 40.0

Solution

1. Step 1: Understand the split_amount method

   It divides total amount by number of people in split_between list.

2. Step 2: Calculate the split

   Amount = 120, split_between has 3 people, so 120 / 3 = 40.0.

3. Final Answer:

   40.0 -> Option D

4. Quick Check:

   120 divided by 3 = 40.0 [OK]

Hint: Divide amount by count of split_between list [OK]

Common Mistakes:

• Forgetting to divide by number of people
• Dividing by 2 instead of 3
• Assuming paid_by affects split amount

4. Identify the bug in this Expense class method that calculates each user's share:

class Expense:
    def __init__(self, amount, paid_by, split_between):
        self.amount = amount
        self.paid_by = paid_by
        self.split_between = split_between

    def split_amount(self):
        return self.amount // len(self.split_between)

medium

A. Using integer division (//) may lose cents in split

B. split_between should be a dictionary, not a list

C. paid_by should be a list, not a single user

D. amount should be a string, not a number

Solution

1. Step 1: Analyze the division operator used

   The method uses integer division (//) which truncates decimals.

2. Step 2: Understand impact on money split

   Using // can lose fractional cents, causing inaccurate splits.

3. Final Answer:

   Using integer division (//) may lose cents in split -> Option A

4. Quick Check:

   Integer division truncates decimals, causing loss [OK]

Hint: Use float division (/) for accurate money splits [OK]

Common Mistakes:

• Ignoring decimal loss from integer division
• Confusing data types for paid_by or split_between
• Thinking amount should be string

5. You want to design a system where multiple users in a group can add expenses, and the system automatically calculates how much each user owes or is owed. Which design approach best supports scalability and clear responsibility?

hard

A. Make User class handle all expense calculations and group management to centralize logic

B. Use only a single Expense class that stores all users and groups inside it to simplify design

C. Create User, Group, and Expense classes where Group manages users and expenses; Expense tracks amount and split; User tracks individual balances updated by Group

D. Store all data in a flat file and calculate splits manually each time without classes

Solution

1. Step 1: Identify responsibilities for each class

   User holds personal info and balances, Group manages users and expenses, Expense tracks costs and splits.

2. Step 2: Evaluate design for scalability and clarity

   Create User, Group, and Expense classes where Group manages users and expenses; Expense tracks amount and split; User tracks individual balances updated by Group cleanly separates concerns, making it easier to maintain and scale.

3. Final Answer:

   Create User, Group, and Expense classes where Group manages users and expenses; Expense tracks amount and split; User tracks individual balances updated by Group -> Option C

4. Quick Check:

   Clear class roles = scalable design [OK]

Hint: Separate concerns: User, Group, Expense each handle distinct roles [OK]

Common Mistakes:

• Putting all logic in one class
• Ignoring separation of concerns
• Using flat files for complex data