Decide Data Models for Zplit App.

[M4dhav]

This issue will track discussions related to finalizing the data models for the application. As this is a purely offline application, we will use a SQL Database offline to store all data. To transfer this data between devices, the currently ideated architecture will involve encoding any data to transferrable strings and then decoding on the receiving device.

One Data Structure proposed by Bruno is:
Payer-Debtor-Amount-Total-Currency-Description-Category-Location(optional)-Date and Time

Example for a $100 Transaction paid by X and split between X,Y and Z:
If X creates a record for this, the following transactions will be created by X and then later synchronised with Y's device:
X-Y-33-100-USD-Dinner-XYTrip-20S 40E-2025-12-03 18:00
X-Z-33-100-USD-Dinner-XYTrip-20S 40E-2025-12-03 18:00

[M4dhav]

This is my alternate Architecture for Zplit. The bigger boxes represent tables and the smaller boxes are rows with fields.

[M4dhav]

Please share your own proposed architectures for consideration and offer feedback on our ideas

[4555jan]

@M4dhav i have one question in this data model that what if an expense needs to be edited example description, category, date, or even amount than how are we going to identify all rows belonging to the same expense across devices ?

[M4dhav]

@M4dhav i have one question in this data model that what if an expense needs to be edited example description, category, date, or even amount than how are we going to identify all rows belonging to the same expense across devices ?

In Bruno's proposed Architecture, this would require querying and modifying all rows which we could relate with a transaction ID.

My architecture uses a relational DB, so we would still need to query with the transaction ID, but a query to the Transaction table would also return linked documents related to Splits, although for editing Transaction specific details, we only need to modify the Transaction Row

[4555jan]

this is a rough model i made and idea is that in this an expense is like a single entity with a version number
so when editing (description, date, category) only modifies the Expenses row but changes to amount or participants recreate the
corresponding splits. and for sync devices exchange expense row , related splits and a version so every expense will have a number (version)
--- in the expenses table there is a attribute called version i forgot to add
in this version changes on every edit for example there is a original expense and Person A and B edits something offline so both of their version's will bump now so because of this we will always increment version on save if anything changed....... please tell me what you think about this @M4dhav

[Piyushbijarania]

i tried visualizing a small simplification that keeps the model offline friendly

the idea is to separate

• the context of an expense (Expense_Event), and
• the result (Due: who owes whom and how much).

this is something likw which have both group splits and ledger like entries.

[Hemil36]

I would really like to get clarity on a few foundational points as this will affect the Schema:

1. What is the canonical unit of truth?
   Are we considering individual split rows, a versioned expense entity, or events (like expense created / payment made) as the source of truth?

2. How should concurrent offline edits to monetary fields be handled?
   If two devices modify the amount or split of the same expense while offline, what is the intended resolution strategy like last-write wins ?

3. What must be the explicit sync conflict policy?

[4555jan]

@Hemil36 you are talking about my model right?

[Hemil36]

@4555jan Yes, I’m referring to all the proposed models so far, including Bruno’s, M4dhav’s, and yours

Bruno’s approach treats individual split rows as the primary data, which raises questions of syncing when multiple rows belong to the same logical expense.

M4dhav’s relational model introduces a clear Transaction entity with linked splits, which helps structurally, but still have doubts on how offline edits and conflicts are handled during sync.

your versioned expense model improves edit handling by bumping versions, but concurrent offline edits can still lead to conflicts that versioning alone doesn’t resolve.

The questions I raised , are meant to clarify which assumptions we are making across these models, since each one implicitly answers them differently .

[SiddharthJiyani]

My understanding of the approaches so far

The main difference between the proposed models is what we treat as the canonical unit of truth during sync as rightly pointed out by @Hemil36.

• Bruno’s model implicitly treats individual split rows as the unit of truth. An expense is emergent from multiple rows that share metadata.
  This makes peer-to-peer sync very robust and additive, but expense-level edits (description, category, date) require updating multiple rows and can lead to partial inconsistency.

• @M4dhav’s relational model introduces an explicit Expense (or Transaction) entity with linked splits.
  This makes editing and querying cleaner. Here, the expense (with its version) becomes the unit of truth, and splits are dependent children. This simplifies modeling but moves conflict handling to the expense level.

• @4555jan’s points highlight an important gap across these models.
  Treating an expense as a versioned entity helps group related rows across devices, but versioning alone only detects that something changed, it does not resolve concurrent offline edits.

One sync issue that seems important to clarify is conflict: when two devices independently modify the same expense offline and later we don’t know which result should be considered correct.

For example, starting from the same expense, one device edits the description while another edits the date. Both versions increment, but when synced they have the same expense_id or tr_id and version with different content. Versioning detects divergence, but does not define what should happen next. This becomes even more critical when amount or split changes are involved.

Because of this, it feels useful to explicitly agree on what the canonical unit of truth is and what conflict-resolution strategy we want, independent of the exact schema.

[4555jan]

@SiddharthJiyani @Hemil36 version is gonna change in increasing
order in every small edit in the expense and bump version again when saving so the version with higer number gets saved between 2 or a group of people

[SiddharthJiyani]

Agreed @4555jan !
Have a look at this: https://www.geeksforgeeks.org/computer-networks/vector-clocks-in-distributed-systems/
We can use vector clocks instead of normal versions!

@M4dhav, Also we will have to make Conflict Resolution Policies and write Sync Protocol, right ?