Google Docs and Chess Design Queries
When we use Google docs when we are sharing a document with someone else. Both will be able to edit the content of the docs. This makes it difficult to design the algorithm as we will have to lock based on the ranges.
A specific algorithm is used for these kinds of test collaborations.
The Operational Transform
The algorithm is very complex. There is a video available in the System Design course for your reference.
Let's move to the Chess design:
The Chess design is going to have a gateway.
The gateway speaks to another service that stores session data which does a protocol translation.
In a chess design, the app should make regular changes. Different clients speak to the app to hit the services.
The problem:
If the API has a breaking change then all the clients need to be updated and restarted.
When changing a version of the library you need to update and restart the services.
The key here is to keep the gateway dumb as possible so that you do need not to restart the gateway.
•Minor changes are not relevant
• Services are not relevant
• Breaking changes are not relevant
The service registry needs to be dumb as possible. Apart from a reverse proxy it also acts as a parser.
Let's say you are in version 3 of Google Docs and google docs says that a person deleted a character from the doc that will be stored in a new version.
What happens is that one keeps drifting away from the lattice point. Eventually, the events are mapped to the current state. The algorithm will tell you how to do that. Each operation is mapped which will end up in the final result.
Further, let's see what exciting discussions we have and how to approach them. Head to watch the full video to learn more!