Requirements

Imagine you're building a simplified version of Splitwise, a popular app for tracking shared expenses among friends. The core problem revolves around managing users, groups, and expenses, ensuring fair distribution of costs, and displaying settlement amounts to equalize debts. This isn't just about storing data; it's about designing a system that handles complex relationships between users, groups, and transactions, and does so in a way that's easy to understand, maintain, and extend. This coding problem focuses on the core logic of splitting expenses and calculating who owes whom. We will focus on in-memory calculations for simplicity, rather than persistence. # Requirements ## Functional Requirements 1. **User Management:** * Create and manage users (name, email, phone number). * Each user should have a unique ID. 2. **Group Management:** * Create groups (name, description). * Add and remove users from groups. * A group can be associated with a currency. * A group should have a unique ID. 3. **Expense Management:** * Add expenses to groups. * Each expense has: * A description. * The user who paid the expense (payer). * The total amount. * The group the expense belongs to. * A list of users who are part of the expense (split between). * A method of splitting the expense (EQUAL, EXACT, PERCENTAGE). * Support different expense splitting strategies: * **EQUAL:** The expense is split equally among the participants. * **EXACT:** Each participant owes a specific amount. * **PERCENTAGE:** Each participant owes a percentage of the total amount. 4. **Settlement Calculation:** * Calculate the amount each user owes or is owed within a group. * Determine the minimum transactions required to settle the debts within a group. For example, instead of A owes B $10 and B owes C $10, we can settle with A owes C $10. * Display the settlement transactions in a user-friendly format. 5. **Currency Handling:** * Expenses and groups can be associated with a currency. * The system should support multiple currencies. For simplicity, currency conversion is not required for this problem. Just ensure that expenses within a group are in the same currency as the group itself. ## Non-Functional Requirements 1. **Modularity:** The code should be well-organized into modules/classes with clear responsibilities. Changes to one module should have minimal impact on others. 2. **Extensibility:** The design should easily accommodate new expense splitting strategies (e.g., ratios) or currency types without requiring major code overhauls. Using design patterns to achieve this is essential. 3. **Testability:** The code should be designed to be easily testable, with well-defined interfaces and dependencies that can be mocked or stubbed. 4. **Readability:** Code should be well-documented and easy to understand. Follow coding conventions and use meaningful names. 5. **Thread Safety:** While the core calculations may be single-threaded for simplicity, consider how the system could be made thread-safe if concurrent access to user/group/expense data were required. Think about potential race conditions and how to avoid them (e.g., using appropriate synchronization mechanisms or immutable data structures, if applicable). Consider the impact of multiple users adding expenses to the same group concurrently. ## Core Entities 1. **User:** Represents a user in the system. Attributes include ID, name, email, and phone number. 2. **Group:** Represents a group of users sharing expenses. Attributes include ID, name, description, and a list of users. 3. **Expense:** Represents an expense within a group. Attributes include ID, description, payer (user), amount, list of participants (users), and splitting strategy. 4. **SplittingStrategy:** An interface or abstract class that defines the contract for splitting expenses. Concrete implementations include EqualSplittingStrategy, ExactSplittingStrategy, and PercentageSplittingStrategy. 5. **Transaction:** Represents a settlement transaction, indicating who owes whom and how much. This could be a simple data class. 6. **Currency:** Represents the currency type for expenses and groups. 7. **Ledger:** The ledger is a central component responsible for tracking all expenses and user balances within groups. It's the heart of the settlement calculation logic.

Design Splitwise.

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content