Scaling Splitwise- How It Is Achievable Invoking Caching

Scaling via Invoking Data Inconsistency:

We need to take care to maintain consistency and synchronization of the system.  It is because just like in designing ATM machines we need to keep a stronghold that any transactions or operations should not be let go or get duplicated as created. 

Suppose A transfers all of its available funds to B. Ofcource’s combined balance remains the same, it just transfers from one account to another and is therefore being tracked via this app. But what if during this write operation, there is another read operation over A at the same time, and the value overwrites with some other value or any garbage value or 0? Now our data becomes inconsistent. Hence in order to solve this problem we do have 2 solutions with us:

1. Read Locks: Put read lock when updating expenses While updating the expense objects we will not allow users to read data. It will make sure that the data users get will be consistent.
2. Making objects mutable: Make objects immutable So whenever there is an edit request we will create a new object and update data in a new object. Once the update is completed we will point the reference to the new object. Users might get old data however we can be sure that data will be consistent. This will make our system eventually consistent. 

Scaling (Actual Splitwise Application)

If  we look carefully at API then look at these 2 APIs as listed below: 

PaymentGraph getGroupPaymentGraph()
Expenses[] getGroupExpenses(GroupID groupo_id)

In this post, we will look into the System Design of Expense Sharing Applications such as Splitiwse. We will deep dive into the LLD of Splitwise, the Happy Flow of Splitwise, and also how to design the backend for Splitwise or such Expense Sharing Applications.