Low-Level Design (LLD) of Splitwise: System Design Interview Guide

Mastering the low-level design of real-world applications is a staple of system design interviews. One of the most frequently asked machine-coding and LLD problems is designing an expense-sharing application like Splitwise.

Get Rajeev Kumar’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This article breaks down the complete LLD of Splitwise, covering core requirements, entity modeling, design patterns, balance calculation algorithms, and the end-to-end request flow.

What is Splitwise?

Splitwise is an application that helps friends split expenses, track balances, and settle up debts.

• Core Features: Create groups, add members, add expenses, split expenses (Equal, Exact, Percentage), view balances, and settle up.

1. Core Entities and Classes

To design Splitwise, we need to model the domain objects effectively. The system revolves around six main entities: User, Group, Expense, Split, Balance, and Payment.

Class Definitions & Relationships

• User: Represents an application user with attributes like id, name, email, and mobile.
• Group: Represents a collection of users (e.g., a “Trip to Manali” group). A user can be part of multiple groups, and a group has multiple members managed via a GroupMember relationship.
• Expense: Represents a bill paid by a user inside a group. It includes attributes like id, description, amount, paidBy, and group.
• Split: Tracks individual shares for an expense. Each expense is divided into multiple splits.
• Balance: Tracks who owes whom and how much between two users. A positive balance means “to receive” and a negative balance means “to pay”.
• Payment: Represents money transferred to clear balances (settlement), tracking fromUser, toUser, amount, and status (PENDING, COMPLETED, FAILED).

2. Split Strategy (Strategy Pattern)

Different expenses require different splitting logic (Equal, Exact, or Percentage). To adhere to the Open-Closed Principle, we use the Strategy Pattern.

• Interface: SplitStrategy defines a single method: split(double amount, List<User> users).
• Implementations:
• EqualSplitStrategy: Divides the total amount equally among all users.
• ExactSplitStrategy: Assigns exact monetary amounts provided in the request to each user.
• PercentageSplitStrategy: Calculates individual shares based on given percentage values ($amount \times percent / 100$).
• Factory Pattern: A SplitStrategyFactory evaluates the split type and instantiates the appropriate strategy dynamically at runtime.

Java

public interface SplitStrategy {
    List<Split> split(double amount, List<User> users);
}

3. Balance and Settlement System

Balances define the net financial position between users within a group.

• Balance Model: Contains id, fromUser (who owes), toUser (who should receive), and amount.
• Calculation Flow: When an expense is added, the system calculates individual shares, determines net positions, and updates the respective balances.
• Settlement Service: Handles transactions when a user pays back another user. Settling an amount reduces or clears the balance to zero and creates a Payment record.

4. Service Layer Architecture

The service layer contains the core business logic and orchestrates workflows across components:

• ExpenseService: Manages addExpense(), fetching group expenses, and triggering balance updates.
• BalanceService: Calculates and retrieves net balances for users and groups.
• SettlementService: Manages the settle() workflow, processes payments, and updates transaction histories.
• GroupService: Handles group creation, adding/removing members, and fetching group details.

5. End-to-End Request Flow (Adding an Expense)

When a user adds an expense inside a group, the execution follows these sequential steps:

• Validation: The system validates the group and participating users.
• Strategy Selection: An appropriate SplitStrategy (Equal, Exact, or Percentage) is selected via the factory.
• Calculation: The strategy computes individual shares for each participant.
• Persistence: The expense and its corresponding splits are saved to the database via the repository layer.\
• Balance Update: The BalanceService recalculates and updates net balances.
• UI Refresh: Updated balances immediately become visible to all group members.

LLD Interview Questions & Key Takeaways

• How do you add a new split type? You can introduce a new split type (e.g., Share-based splitting) without modifying existing code by simply creating a new class that implements the SplitStrategy interface.
• Why use the Strategy and Factory patterns? They decouple the business logic from specific split algorithms, making the codebase clean, modular, and easy to scale.

Happy Building! :)

Connect with me on:

LinkedIn Profile: https://www.linkedin.com/in/rajeev-kumar-nit/
Github: https://github.com/RajK01
Medium: https://medium.com/@rajeev001