Split strategies (equal, exact, percentage) in LLD - System Design Exercise

Design: Bill Splitter System

Design focuses on the core logic and architecture for split strategies and participant management. UI design, payment processing, and user authentication are out of scope.

Functional Requirements

FR1: Allow users to split a bill among multiple participants using different strategies: equal, exact, and percentage.

FR2: Equal split divides the total amount equally among all participants.

FR3: Exact split allows specifying the exact amount each participant pays.

FR4: Percentage split allows specifying the percentage of the total amount each participant pays.

FR5: Validate that the sum of exact amounts or percentages matches the total bill amount.

FR6: Support adding, updating, and removing participants and their split details.

FR7: Provide a summary of each participant's payable amount.

FR8: Handle bills with up to 100 participants.

Non-Functional Requirements

NFR1: The system should respond within 200ms for split calculations.

NFR2: Support concurrent updates from multiple users on the same bill with consistency.

NFR3: Ensure data accuracy and validation to prevent incorrect splits.

NFR4: Availability target of 99.9% uptime.

NFR5: Memory usage should be optimized for mobile and web clients.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Bill management module

Split strategy handler

Validation service

Participant management

API layer for client interaction

Data storage for bills and participants

Design Patterns

Strategy pattern for split calculation

Observer pattern for updates and notifications

Transaction management for concurrent updates

Validation and error handling patterns

Reference Architecture

  +-------------------+       +---------------------+       +-------------------+
  |                   |       |                     |       |                   |
  |   Client (UI)     +------>+  API Layer           +------>+  Split Strategy    |
  |                   | REST  |  (REST/GraphQL)      |       |  Handler          |
  +-------------------+       +---------------------+       +---------+---------+
                                                                       |
                                                                       v
                                                              +-------------------+
                                                              | Validation Service |
                                                              +---------+---------+
                                                                        |
                                                                        v
                                                              +-------------------+
                                                              |  Data Storage      |
                                                              | (Relational DB)    |
                                                              +-------------------+

Components

Client (UI)

Web/Mobile frontend

Interface for users to input bill details, select split strategy, and view results.

API Layer

REST or GraphQL API

Handles client requests, routes to appropriate services, and returns responses.

Split Strategy Handler

Backend service implementing Strategy pattern

Calculates split amounts based on selected strategy (equal, exact, percentage).

Validation Service

Backend validation module

Ensures correctness of splits, sums, and participant data before saving.

Data Storage

Relational Database (e.g., PostgreSQL)

Stores bills, participants, split details, and history.

Request Flow

1. User inputs bill total and participant details via Client UI.

2. Client sends request to API Layer with split strategy and participant data.

3. API Layer forwards data to Split Strategy Handler.

4. Split Strategy Handler calculates each participant's payable amount based on strategy:

5. - Equal: divides total by number of participants.

6. - Exact: uses specified amounts per participant.

7. - Percentage: calculates amounts from percentages.

8. Validation Service checks if sums match total and data is consistent.

9. If validation passes, data is saved to Data Storage.

10. API Layer returns split summary to Client UI for display.

Database Schema

Entities: - Bill: id (PK), total_amount, currency, created_at, updated_at - Participant: id (PK), bill_id (FK), name, contact_info - SplitDetail: id (PK), participant_id (FK), split_type (enum: equal, exact, percentage), amount, percentage Relationships: - One Bill has many Participants - Each Participant has one SplitDetail Constraints: - Sum of SplitDetail.amount per Bill must equal Bill.total_amount - For percentage splits, sum of SplitDetail.percentage per Bill must be 100%

Scaling Discussion

Bottlenecks

High concurrency when multiple users update the same bill simultaneously causing race conditions.

Validation logic becoming slow with large number of participants (close to 100).

Database write contention on bill and participant tables.

API Layer becoming a bottleneck under heavy load.

Solutions

Implement optimistic locking or transactions to handle concurrent updates safely.

Optimize validation logic with early exits and caching intermediate results.

Use database indexing and partitioning to improve write performance.

Scale API Layer horizontally with load balancers and stateless services.

Interview Tips

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

Explain different split strategies clearly with examples.

Describe how Strategy pattern helps in clean design and extensibility.

Discuss validation importance and how to handle errors.

Highlight concurrency challenges and solutions.

Mention scalability considerations and how to maintain low latency.

Practice

1. Which split strategy divides an amount so that everyone pays the same share regardless of individual preferences?

easy

A. Equal split

B. Exact split

C. Percentage split

D. Random split

Solution

1. Step 1: Understand the definition of equal split

   Equal split means dividing the total amount evenly among all participants.

2. Step 2: Compare with other splits

   Exact split assigns specific amounts, percentage split assigns based on percent, random split is not a standard method.

3. Final Answer:

   Equal split -> Option A

4. Quick Check:

   Equal split = same share for all [OK]

Hint: Equal split means everyone pays the same amount [OK]

Common Mistakes:

• Confusing exact split with equal split
• Thinking percentage split always equals equal split
• Assuming random split is a valid standard method

2. Which of the following is the correct syntax to represent a percentage split of 40% for user A and 60% for user B in a system design context?

easy

A. {'A': '40%', 'B': '60%'}

B. {'A': 40, 'B': 60}

C. {'A': 0.4, 'B': 0.6}

D. {'A': 4, 'B': 6}

Solution

1. Step 1: Understand percentage representation in decimals

   Percentages are often represented as decimals between 0 and 1 in code for calculations.

2. Step 2: Evaluate options

   {'A': 0.4, 'B': 0.6} uses decimals summing to 1, correct for percentage split. {'A': 40, 'B': 60} uses integers but not decimals. {'A': '40%', 'B': '60%'} uses strings which are not directly usable. {'A': 4, 'B': 6} uses incorrect smaller numbers.

3. Final Answer:

   {'A': 0.4, 'B': 0.6} -> Option C

4. Quick Check:

   Decimal form for percentages = {'A': 0.4, 'B': 0.6} [OK]

Hint: Use decimals (0.4) not integers (40) for percentage splits [OK]

Common Mistakes:

• Using integers instead of decimals for percentages
• Using strings with % symbol in code
• Not ensuring sum equals 1

3. Given a total amount of 100 and a split strategy: {'A': 30, 'B': 70} as exact amounts, what is the amount assigned to user B?

medium

A. 70

B. 100

C. 30

D. 0

Solution

1. Step 1: Identify the split type and amounts

   The split is exact, so amounts are assigned directly as given.

2. Step 2: Find user B's assigned amount

   User B is assigned 70 as per the exact split dictionary.

3. Final Answer:

   70 -> Option A

4. Quick Check:

   Exact split assigns given amounts = 70 [OK]

Hint: Exact split means use given amounts directly [OK]

Common Mistakes:

• Adding amounts instead of reading assigned value
• Confusing exact with percentage split
• Assuming equal split when exact is given

4. In a percentage split system, if the sum of percentages provided is 110%, what is the main issue and how should it be fixed?

medium

A. The sum is valid, no fix needed

B. The sum should be exactly 0%, reset all percentages

C. The sum is less than 100%, add missing percentage

D. The sum exceeds 100%, fix by normalizing percentages to sum to 100%

Solution

1. Step 1: Identify the problem with sum of percentages

   Percentages must sum to 100% (or 1 in decimal) to correctly split amounts.

2. Step 2: Determine the fix

   If sum is 110%, it exceeds total amount. Normalize by scaling percentages so they sum to 100%.

3. Final Answer:

   The sum exceeds 100%, fix by normalizing percentages to sum to 100% -> Option D

4. Quick Check:

   Sum > 100% requires normalization [OK]

Hint: Percentages must sum to 100%, else normalize [OK]

Common Mistakes:

• Ignoring sum validation
• Assuming sum can be more than 100%
• Trying to add missing percentage when sum is too high

5. You need to design a system that supports splitting a bill among users using equal, exact, or percentage strategies. Which approach best ensures scalability and correctness when handling thousands of users?

hard

A. Allow users to input any split without checks and calculate on demand

B. Use a unified split interface that validates input and applies the correct split logic per strategy

C. Store all splits as exact amounts without validation

D. Hardcode equal split only to simplify calculations

Solution

1. Step 1: Identify requirements for scalability and correctness

   System must handle many users and ensure splits are valid and consistent.

2. Step 2: Evaluate design approaches

   Unified interface with validation ensures correctness and flexibility. Hardcoding or no validation risks errors and poor scalability.

3. Final Answer:

   Use a unified split interface that validates input and applies the correct split logic per strategy -> Option B

4. Quick Check:

   Unified validated interface = scalable & correct [OK]

Hint: Validate splits and use unified logic for scalability [OK]

Common Mistakes:

• Ignoring validation leading to incorrect splits
• Hardcoding one strategy limits flexibility
• Allowing unchecked input causes errors at scale