diff --git a/README.md b/README.md
index 79d11f2..54136f4 100644
--- a/README.md
+++ b/README.md
@@ -51,4 +51,6 @@ Az **auto-increment-increment** azt is meghatározza, hogy hány szerver vehet r
 
 A lokális adatbázisban keletkező elsődleges kulcsok képzését meg lehetne oldani a mysql replikációnál használt megoldással, de az további adminisztrációt eredményezne, minden résztvevő kliensnek egyedi sorszámmal kellene rendelkeznie, előre kellene tudni a résztvevő adatbázisok számát, és, ha az mégis kevésnek bizonyul, az összes adatbázison újra kellene konfigurálni az elsődleges kulcsokat és azok képzését is.
 
-Inkább az a megoldás lett használva, hogy a helyi adatbázisokban keletkezett elsődleges kulcsok nem kerülnek szinkronizálásra.
+Inkább az a megoldás lett használva, hogy a helyi adatbázisokban keletkezett elsődleges kulcsok nem kerülnek szinkronizálásra, a rekordok azonosítása egy-egy uuid-val történik, az egymáshoz kapcsolt táblák is a uuid-k révén vannak összekötve. Annak az esélye, hogy egy már létező uuid újra előkerül, elhanyagolhatóan kicsi, gyakorlatikag egymástól függetlenül tundak a kliensek olyan azonosítókat generálni, amiből nem lesz két egyforma.
+
+Kliens oldalon minden nem select típusú lekérdezés egy táblába íródik, amit rest api-n keresztül tölt fel a rendszer. A helyi adatbázisban lévő elsődleges kulcsot használja fel azonosításra és nyugtázásra is, ott minden feltöltött lekérdezés egy adattáblába íródik. A kliensek ezt az adattáblát kérdezik le a beírás sorrendjében, amit a kiszolgáló által létrehozott elsódleges kulcs segítségével követnek, és amelyik lekérdezést nem a kérdező töltötte fel, az végrehajtódik a lokális adatbázison is, így szinkronban tartva a klienseken tárolt adatbázisokat.