> For the complete documentation index, see [llms.txt](https://avinandanbanerjee99.gitbook.io/system-design-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://avinandanbanerjee99.gitbook.io/system-design-notes/examples/google-sheets.md).

# Google Sheets

### Data Modeling

A relational design such as the follows fails -

```
Table Sheet
- Sheet ID
- Sheet Metadata
- Row[]

Table Row
- Row ID
- Columns[]

Table Column
- Column ID
- Data
```

This is because of the extremely large overhead of table joins. If there can be max 1000 rows and 100 columns, it can take 10^5 joins to load a single sheet for just one user! 

A better NoSQL design

```
Tuples of the form
- Sheet ID
- Row Number
- Row JSON
    - {
        [
           colNum,
           data      
        ],
        ...
       }
```

However, if we insert a new row, all rows after the new row have to change their Row ID. Similar issues for inserting new columns.

```
- Sheet ID
- Row ID
- Next Row ID (Similar to LinkedList)
- Row JSON
```

With this design, we can insert a row in the middle only by rearranging the next ID for one row, and DB updates do not have to happen for the remainder.

How to handle new columns? Unfortunately, we will have to loop through all rows, and update rowJSON in a similar spirit for columns. Hence it is easier to add rows than columns.

### Collaborative Editing

Operational Transformations (see Google Docs) might be too complicated. Last Write Wins might be a better policy.