Sync Engine: βασικές έννοιες, τύποι και μηχανισμοί λειτουργίας

Τι είναι η μηχανή συγχρονισμού;

Sync Engine — είναι ένα αρχιτεκτονικό επίπεδο μεταξύ της τοπικής βάσης δεδομένων και του απομακρυσμένου API που διαχειρίζεται τη ροή δεδομένων και προς τις δύο κατευθύνσεις. Τα καθήκοντά του: παρακολούθηση αλλαγών, αποστολή τους στον διακομιστή, λήψη αλλαγών από τον διακομιστή και επίλυση συγκρούσεων. Ο χρήστης εργάζεται με τοπικά δεδομένα και το Sync Engine τα συγχρονίζει απρόσκοπτα με τον διακομιστή.

Το Sync Engine μπορεί να είναι ενσωματωμένο (Firebase Firestore, Couchbase Lite, Realm) ή προσαρμοσμένο — γραμμένο για συγκεκριμένη επιχειρηματική λογική. Τα ενσωματωμένα μηχανήματα προσφέρουν έτοιμη λειτουργικότητα offline-first και επίλυση συγκρούσεων. Τα προσαρμοσμένα δίνουν πλήρη έλεγχο στη μορφή δεδομένων, το πρωτόκολλο συγχρονισμού και την πολιτική συγκρούσεων.

Σύμφωνα με τον Sravan Kartik (2024), συγγραφέα του βιβλίου «Mobile Sync Engine Design Patterns», το προσαρμοσμένο Sync Engine δικαιολογείται για εφαρμογές με πολύπλοκη επιχειρηματική λογική (οικονομικά, ιατρική, IoT), όπου οι προσαρμοσμένοι κανόνες συγχώνευσης είναι κρίσιμοι. Για τυπικά σενάρια (σημειώσεις, συνομιλίες, ροές) αρκούν τα ενσωματωμένα Firestore ή Realm.

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

Αυτή η διεπαφή περιγράφει την ελάχιστη σύμβαση του Sync Engine: pull (λήψη αλλαγών από τον διακομιστή), push (αποστολή τοπικών αλλαγών), resolve (διαχείριση συγκρούσεων) και observe (παρακολούθηση κατάστασης συγχρονισμού). Αυτή η αφαίρεση επιτρέπει την αλλαγή υλοποίησης χωρίς τροποποίηση του επιπέδου παρουσίασης.

Τύποι συγχρονισμού: πλήρης, αυξητικός και push

Full sync (πλήρης συγχρονισμός) — σε κάθε συνεδρία γίνεται λήψη ολόκληρου του συνόλου δεδομένων από τον διακομιστή. Απλή υλοποίηση, αλλά απαράδεκτη για μεγάλους όγκους: η λήψη 10.000 εγγραφών σε κάθε άνοιγμα της εφαρμογής καταναλώνει κίνηση και μπαταρία. Το full sync δικαιολογείται για δεδομένα αναφοράς (λίστα χωρών) με σπάνιες ενημερώσεις.

Incremental sync (αυξητικός συγχρονισμός) — μεταφέρονται μόνο οι εγγραφές που άλλαξαν από τον τελευταίο συγχρονισμό. Ο διακομιστής αποθηκεύει τη χρονική σφραγίδα της τελευταίας αλλαγής για κάθε εγγραφή ή ολόκληρο το σύνολο. Ο πελάτης στέλνει το lastSyncTimestamp και λαμβάνει μόνο εγγραφές με updated_at > αυτήν την τιμή. Σύμφωνα με το Instagram Engineering (2024), ο αυξητικός συγχρονισμός μειώνει τον όγκο των μεταφερόμενων δεδομένων κατά 97% σε σύγκριση με τον πλήρη συγχρονισμό.

Push sync (συγχρονισμός με πρωτοβουλία του διακομιστή) — ο διακομιστής ειδοποιεί ο ίδιος τον πελάτη για την ανάγκη συγχρονισμού μέσω FCM (Firebase Cloud Messaging), WebSocket ή SSE (Server-Sent Events). Ο πελάτης δεν σπαταλά πόρους σε περιοδική polling. Το push sync είναι η βέλτιστη λύση για εφαρμογές πραγματικού χρόνου: συνομιλίες, ειδοποιήσεις, like. Google Firebase Firestore χρησιμοποιεί WebSocket για συγχρονισμό πραγματικού χρόνου με αυτόματη επιστροφή σε HTTP polling.

Υβριδική προσέγγιση — συνδυασμός τύπων: κατά την εκκίνηση της εφαρμογής full sync για βασικά δεδομένα, στη συνέχεια incremental sync για ενημερώσεις, και για κρίσιμα συμβάντα — push sync μέσω FCM. Αυτό προσφέρει και ταχύτητα και εξοικονόμηση πόρων.

Incremental sync — πώς λειτουργούν τα σημεία ελέγχου και τα δέλτα

Σημείο ελέγχου — μια τιμή που αποθηκεύει ο πελάτης μεταξύ των συνεδριών συγχρονισμού. Συνήθως είναι το updated_at της τελευταίας επιτυχώς συγχρονισμένης εγγραφής. Στον επόμενο συγχρονισμό, ο πελάτης στέλνει το σημείο ελέγχου στον διακομιστή, και αυτός επιστρέφει όλες τις εγγραφές με updated_at μεταγενέστερο του σημείου ελέγχου. Cursor-based pagination — μια προηγμένη έκδοση όπου ο διακομιστής επιστρέφει έναν δείκτη (δείκτης στην επόμενη σελίδα) μαζί με τα δεδομένα.

Συγχρονισμός δέλτα — ο διακομιστής υπολογίζει τη διαφορά μεταξύ της τρέχουσας κατάστασης δεδομένων και του στιγμιότυπου που είδε ο πελάτης. Αντί να στέλνονται όλες οι εγγραφές, μεταφέρονται μόνο οι λειτουργίες (insert, update, delete). Αυτό είναι ιδιαίτερα αποτελεσματικό για μεγάλα σύνολα δεδομένων, όπου έχουν αλλάξει μόνο λίγες εγγραφές. Google Drive API (2025) χρησιμοποιεί changes.list με pageToken για συγχρονισμό δέλτα αρχείων.

Στρατηγική «καθυστερημένων δέλτα» — στον κινητό πελάτη, οι αλλαγές δεν αποστέλλονται αμέσως, αλλά αποθηκεύονται προσωρινά στο Offline Queue. Όταν επιτευχθεί το όριο (10 λειτουργίες ή 30 δευτερόλεπτα), σχηματίζεται ένα πακέτο δέλτα και αποστέλλεται στον διακομιστή. Σύμφωνα με το Dropbox Mobile Engineering (2024), η ομαδοποίηση δέλτα μείωσε τον αριθμό των HTTP αιτημάτων κατά 65% και μείωσε την κατανάλωση μπαταρίας κατά 12%.

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

Το SyncCheckpoint αποθηκεύει τόσο τη χρονική σφραγίδα όσο και τον δείκτη σελιδοποίησης για μεγάλες λίστες. Σημείο ελέγχου δύο παραμέτρων εγγυάται ότι καμία εγγραφή δεν θα παραλειφθεί ή θα διπλασιαστεί κατά τον συγχρονισμό μεγάλων συνόλων δεδομένων.

Push sync — άμεσος συγχρονισμός μέσω WebSocket και FCM

WebSocket — μια μόνιμη αμφίδρομη σύνδεση μεταξύ πελάτη και διακομιστή. Ο διακομιστής στέλνει ενημερώσεις αμέσως μόλις αλλάξουν τα δεδομένα. Το WebSocket είναι βέλτιστο για εφαρμογές πραγματικού χρόνου: συνομιλίες, ροή, συνεργατική εργασία. Μειονέκτημα: κατανάλωση μπαταρίας και κίνησης για τη διατήρηση της σύνδεσης (heartbeat). OkHttp WebSocket σε Android και URLSessionWebSocketTask σε iOS — ενσωματωμένες υλοποιήσεις.

Firebase Cloud Messaging (FCM) — ειδοποιήσεις push που στέλνει ο διακομιστής όχι για εμφάνιση στον χρήστη, αλλά για ενεργοποίηση συγχρονισμού. Κατά τη λήψη ενός silent push (data message), η εφαρμογή αφυπνίζεται και εκκινεί το Sync Engine. Το FCM δεν απαιτεί μόνιμη σύνδεση και είναι πιο οικονομικό από το WebSocket για σπάνιες ειδοποιήσεις.

SSE (Server-Sent Events) — ένα μονόδρομο κανάλι μέσω του οποίου ο διακομιστής στέλνει συμβάντα στον πελάτη. Απλούστερο στην υλοποίηση από το WebSocket, αλλά δεν υποστηρίζει αμφίδρομη επικοινωνία. EventSource API (JavaScript) και OkHttp SSE (Android) — δημοφιλείς βιβλιοθήκες. Το SSE είναι κατάλληλο για ειδοποιήσεις σχετικά με νέα δεδομένα όταν ο πελάτης δεν χρειάζεται να στείλει δεδομένα πίσω μέσω του ίδιου καναλιού.

Σύμφωνα με το WhatsApp Engineering (2024), το Sync Engine τους χρησιμοποιεί συνδυασμό WebSocket για ενεργή συνεδρία και FCM για αφύπνιση της εφαρμογής στο παρασκήνιο: το WebSocket αποσυνδέεται μετά από 5 λεπτά αδράνειας και οι επόμενες ενημερώσεις παραδίδονται μέσω silent push.

Snapshot sync και έλεγχος εκδόσεων δεδομένων

Snapshot-based sync — ο διακομιστής δημιουργεί περιοδικά ένα πλήρες στιγμιότυπο (snapshot) των δεδομένων και του αποδίδει μια έκδοση. Ο πελάτης αποθηκεύει τον αριθμό τρέχουσας έκδοσης. Αν είναι ξεπερασμένη — φορτώνει νέο στιγμιότυπο. Αυτή είναι μια απλή και αξιόπιστη στρατηγική, αλλά αναποτελεσματική για συχνές αλλαγές — κάθε φορά φορτώνεται ολόκληρο το σύνολο δεδομένων.

Έλεγχος εκδόσεων σε επίπεδο εγγραφής — κάθε εγγραφή έχει ένα πεδίο version. Κατά τον συγχρονισμό, ο πελάτης στέλνει τις εκδόσεις όλων των εγγραφών και ο διακομιστής επιστρέφει μόνο εκείνες των οποίων η έκδοση άλλαξε. Αυτό είναι πιο αποτελεσματικό από τον snapshot sync, αλλά απαιτεί αποθήκευση εκδόσεων στον πελάτη. Vector Clocks — προηγμένη τεχνική για κατανεμημένα συστήματα, όπου κάθε κόμβος αποδίδει τη δική του έκδοση και οι συγκρούσεις επιλύονται με μερική σειρά.

Snapshot με αυξητική διαφορά — υβριδική προσέγγιση: σπάνιο πλήρες στιγμιότυπο (μία φορά την ημέρα) + αυξητικός συγχρονισμός μεταξύ τους. Μετά από μακρά απουσία, ο πελάτης φορτώνει στιγμιότυπο, και σε συχνούς συγχρονισμούς — μόνο δέλτα. Προσέγγιση παρόμοια με Git — κάθε δέσμευση δεδομένων έχει ένα hash, και ο πελάτης γνωρίζει από ποια δέσμευση να ξεκινήσει. Αυτό υλοποιείται στο Couchbase Lite Sync Gateway (2024) και αποτελεί πρότυπο αξιοπιστίας.

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

Κανόνας επίλυσης εκδόσεων: αν οι εκδόσεις ταιριάζουν — δεν υπάρχουν αλλαγές. Αν η τοπική έκδοση είναι νεότερη — κερδίζει η τοπική. Αν η έκδοση διακομιστή είναι νεότερη — κερδίζει ο διακομιστής. Μόνο σε ίσες εκδόσεις αλλά διαφορετικά δεδομένα — καλείται το conflict resolver. Last Write Wins με σημαία version — η απλούστερη αλλά αξιόπιστη στρατηγική.

Πώς να δημιουργήσετε Sync Engine για εφαρμογή κινητού

Βήμα 1: Καθορισμός μοντέλου δεδομένων — ποιες οντότητες συγχρονίζονται, πόσο συχνά αλλάζουν, ποιος είναι ο όγκος τους. Για κάθε οντότητα καθορίστε στρατηγική (incremental / full / push) και επιτρεπόμενη καθυστέρηση συγχρονισμού.

Βήμα 2: Επιλογή πρωτοκόλλου — REST με σημεία ελέγχου, GraphQL με Subscriptions ή gRPC με αμφίδρομη ροή. GraphQL Subscriptions — δημοφιλής επιλογή για σύγχρονες εφαρμογές: ένα πρωτόκολλο τόσο για pull όσο και για push. Το Apollo Client (2025) υποστηρίζει offline συγχρονισμό μέσω προσωρινής αποθήκευσης στη συσκευή.

Βήμα 3: Υλοποίηση Offline Queue — τοπική αποθήκευση αλλαγών με κλειδιά idempotency (δείτε το άρθρο «Offline Queue»). Η ουρά είναι το θεμέλιο ενός αξιόπιστου Sync Engine: χωρίς αυτήν, ο συγχρονισμός δεν εγγυάται την παράδοση αλλαγών.

Βήμα 4: Επιλογή conflict resolver — LWW για απλές περιπτώσεις, CRDT για κοινή επεξεργασία, Custom merge για επιχειρηματική λογική. Κανόνας: ο resolver πρέπει να είναι idempotent — η επανειλημμένη εφαρμογή της ίδιας λειτουργίας πρέπει να δίνει το ίδιο αποτέλεσμα.

Βήμα 5: Παρακολούθηση και μετρήσεις — καταγράψτε κάθε συγχρονισμό: αριθμός εγγραφών, χρόνος εκτέλεσης, αριθμός συγκρούσεων, σφάλματα. Firebase Crashlytics ή Sentry (2025) επιτρέπουν την παρακολούθηση σφαλμάτων συγχρονισμού σε πραγματικό χρόνο.

Σύμφωνα με το Realm Team (2024), ένα τυπικό Sync Engine για εφαρμογή κινητού επεξεργάζεται 100–500 συγχρονισμούς την ημέρα ανά συσκευή, μεταφέροντας κατά μέσο όρο 50–200 KB δεδομένων ανά συνεδρία. Βελτιστοποίηση πρωτοκόλλου — συμπίεση Protobuf αντί JSON — μειώνει τον όγκο των μεταφερόμενων δεδομένων κατά επιπλέον 40–60%.