Fire safety in version control systems

Today, there are two types of version control systems: client-server and distributed. But despite the huge difference between them, we still continue to use the central server to synchronize work between team members.
And what will happen if one day the central server burns out?
Let's discuss it

Client server architecture

These version control systems include CVS, SVN. When working with such systems, you must have a server on which special software for working with versioning will be installed. And each time you receive updates to the source code or commit changes, you turn to this central server. If it collapses, you will lose the entire history of changes, which, alas, cannot be restored. This of course can be solved by backups. As a result, you will lose only the part that was created after the last backup was created.
In contrast to this model, supporters of distributed version control systems advertise them, indicating that they do not need a central server and that this model is more protected from problems in the event of a central server crash.

Distributed architecture

But have you ever seen that in teams where the same git or mercurial is used, they work without a central server? I honestly have never. But adherents of DVCS are still right. When you get the code from the repository of the central server, you not only get the latest version, but also the history of changes, as a result, the whole repository comes to you. You, in turn, can also act as a central server for another team member. But if this team member uploads their changes to your repository, you will need to push these changes further to the central server so that all team members have the latest code. And what do we have? you can’t do without a central server, but in the event of its collapse, you can restore history and everything else. And backups do not play such an important role.

Equidistributed Architecture

Now think about creating such a system where you would not have to keep the server for synchronization, but all team members would always have the current version of the code. I see this system in the following form: all the source code is stored by all team members, but when one team member commits their changes, they are transmitted, for example, to two colleagues, and those, in turn, to two more, and so on the whole team will not be the current version. In terms of fault tolerance, this system looks just perfect. There is no central server, there is no likelihood that data loss will occur during its collapse, nor will you need to spend time recovering lost data after a server crash. But there are also flaws in this idea, namely that if a team consists of a small number of participants (1-2 people), the probability of data loss is very high. One solution to this problem may be to use, after all, a server. On the other hand, it is possible, for example, to distribute the program repository not only among members of the team developing this product, but also among others who have this VCS installed. Of course, for others not related to the development of this product, the code must be encrypted before delivery.

So, from the technical point of view, for the system to work, a service must be installed in the operating system that would accept changes from colleagues, upload to the local repository and redirect the received data further to other team members. When the developer needs to upgrade, he will receive the code from the local repository.
The mechanism for committing changes in this case is as follows: the developer executes the command for committing changes, these changes fall primarily in the local repository, and the service from this repository receives and distributes among the team.
Well, the idea seems to be pretty simple. And there seems to be nothing to add.

And why am I writing this article? And besides, I would like to write a similar system and just share my ideas with the community. And suddenly there are those who would gladly be grateful users of it.

Thanks for attention.