Last Write Wins: τι είναι, μηχανισμός και αρχή λειτουργίας

Τι είναι το Last Write Wins στην ανάπτυξη κινητών;

Last Write Wins (LWW) — είναι η στρατηγική της τελευταίας εγγραφής κατά την επίλυση συγκρούσεων συγχρονισμού. Όταν δύο πελάτες τροποποιούν το ίδιο αντικείμενο δεδομένων, ο διακομιστής λαμβάνει και τις δύο εκδόσεις και επιλέγει αυτήν με το μεγαλύτερο timestamp. Το LWW είναι η προκαθορισμένη στρατηγική σε πολλά κατανεμημένα συστήματα: Firebase Realtime Database, Apache Cassandra, Riak KV και DynamoDB σε λειτουργία τελευταίας εγγραφής.

Σε εφαρμογές κινητών, το LWW είναι ελκυστικό για τρεις λόγους: απλότητα υλοποίησης, ελάχιστη καθυστέρηση και απουσία αλληλεπίδρασης με τον χρήστη. Ο πραγματοποιητής δεν χρειάζεται να γράψει πολύπλοκη λογική συγχώνευσης και ο χρήστης δεν βλέπει διαλογικά επιλογής έκδοσης. Ωστόσο, το τίμημα της απλότητας είναι η πιθανή απώλεια δεδομένων, την οποία δεν μπορούν να αντεξξελθούν όλες οι εφαρμογές.

Σύμφωνα με την έρευνα του Martin Kleppmann (συγγραφέα του „Designing Data-Intensive Applications”, O’Reilly, 2024), το LWW είναι η πιο διαδεδομένη στρατηγική σε συστήματα παραγωγής, που χρησιμοποιείται σε περίπου 70% των κατανεμημένων εφαρμογών όπου είναι αποδεκτή η eventual consistency. Σε 23% των περιπτώσεων, οδηγεί σε μετρήσιμη απώλεια δεδομένων χρηστών.

Πώς λειτουργεί ο μηχανισμός LWW

Ο μηχανισμός LWW βασίζεται στη σύγκριση χρονικών σφραγίδων. Κάθε εγγραφή δεδομένων συνοδεύεται με ένα timestamp που μπορεί να οριστεί από τον πελάτη (client-side timestamp) ή από τον διακομιστή (server-side timestamp). Μετά την ανίχνευση σύγκρουσης, το σύστημα συγκρίνει τα timestamps και των δύο εκδόσεων και αποδέχεται την εγγραφή με τη μεγαλύτερη τιμή. Η δεύτερη έκδοση ή απορρίπτεται ή αποθηκεύεται στο ιστορικό για ελεγχο.

Το client-side timestamp έχει ένα μειονέκτημα: τα ρολόγια στις συσκευές χρηστών μπορεί να είναι αποσυγχρονισμένα. Εάν το τηλέφωνο του χρήστη A υστερεί κατά 5 λεπτά και ο χρήστης B κάνει αλλαγές, η εγγραφή του A μπορεί να θεωρηθεί λανθασμένα νεότερη μετά από τη διόρθωση του ρολογιού. Για αυτό, τα συστήματα παραγωγής χρησιμοποιούν συχνότερα server-side timestamp, το οποίο ορίζεται από τον διακομιστή κατά τη λήψη δεδομένων.

Η λογική LWW με server-side timestamp:

data class SyncDocument(
    val id: String,
    val data: String,
    val serverTimestamp: Long
)

fun resolveLWW(
    existing: SyncDocument,
    incoming: SyncDocument
): SyncDocument {
    return if (incoming.serverTimestamp >= existing.serverTimestamp)
        incoming
    else
        existing
}

Η συνάρτηση resolveLWW λαμβάνει δύο έγγραφα και επιστρέφει αυτό με το μεγαλύτερο timestamp. Σε περίπτωση ισότητας, συνήθως κερδίζει το εισερχόμενο έγγραφο — αυτό εγγυάται ότι τα νέα δεδομένα δεν χάνονται λόγω συμπτωσης σφραγίδων.

Πλεονεκτήματα και μειονεκτήματα του Last Write Wins

Το κύριο πλεονέκτημα του LWW είναι η αλγοριθμική απλότητα. Η στρατηγική δεν απαιτεί αποθήκευση ιστορικού εκδόσεων, ανάλυση αλλαγών σε επίπεδο πεδίου ή επίλυση σύνθετων συγκρούσεων. Ο διακομιστής επεξεργάζεται τη σύγκρουση σε μία μόνο πράξη σύγκρισης, καθιστώντας το LWW τη πιο γρήγορη στρατηγική. Στη Firebase Realtime Database, το LWW επεξεργάζεται μέχρι 100 χιλιάδες συγκρούσεις το δευτερόλεπτο σε έναν κόμβο.

Το κύριο μειονέκτημα — απώλεια δεδομένων κατά τις ανεξάρτητες αλλαγές διαφορετικών πεδίων. Εάν ο χρήστης A άλλαξε το όνομα της εργασίας και ο χρήστης B την περιγραφή, το LWW θα απορρίψει μία από τις εκδόσεις συνολικά, αν και οι δύο αλλαγές θα έπρεπε να διατηρηθούν. Αυτό είναι ιδιαίτερα κρίσιμο για φόρμες, προφίλ και διαμορφώσεις όπου κάθε πεδίο έχει σημασία.

Σύγκριση LWW με εναλλακτικές στρατηγικές:

Παραδείγματα υλοποίησης LWW σε Kotlin

Ας εξετάσουμε την υλοποίηση LWW στο πλαίσιο μιας εφαρμογής κινητής λίστας αγορών όπου πολλά μέλη της οικογένειας μπορούν να προσθέτουν και να σημειώνουν προϊόντα offline. Κάθε στοιχείο λίστας αποθηκεύει ID, όνομα, κατάσταση και χρονική σφραγίδα τελευταίας ενημέρωσης. Κατά τον συγχρονισμό, το LWW εφαρμόζεται για κάθε στοιχείο.

Το βασικό μοντέλο στοιχείου λίστας:

data class ShoppingItem(
    val id: String,
    val name: String,
    val isChecked: Boolean,
    val quantity: Int,
    val lastModified: Long
)

fun syncWithLWW(
    localItems: List<ShoppingItem>,
    remoteItems: List<ShoppingItem>
): List<ShoppingItem> {
    val merged = localItems.toMutableList()

    remoteItems.forEach { remote ->
        val index = merged.indexOfFirst { it.id == remote.id }
        if (index == -1) {
            merged.add(remote)
        } else {
            val local = merged[index]
            merged[index] = if (remote.lastModified >= local.lastModified)
                remote
            else
                local
        }
    }
    return merged
}

Η συνάρτηση syncWithLWW συγχωνεύει τις τοπικές και απομακρυσμένες λίστες: εάν ένα στοιχείο υπάρχει μόνο σε μία πλευρά — προστίθεται, εάν και στις δύο — κερδίζει η νεότερη έκδοση. Αυτή η προσέγγιση εξασφαλίζει ντετερμινιστικό συγχρονισμό για κάθε μεμονωμένο στοιχείο.

LWW εναντίον Merge: τι να επιλέξουμε

Η επιλογή μεταξύ LWW και Merge καθορίζεται από τη φύση τροποποίησης δεδομένων. Εάν η εφαρμογή επιτρέπει ανεξάρτητες αλλαγές πεδίων (διαφορετικοί χρήστες τροποποιούν διαφορετικά πεδία του ίδιου αντικειμένου), η Merge Strategy θα διατηρήσει τα δεδομένα πιο επακριβώς. Εάν οι αλλαγές είναι πάντα ατομικές (ο χρήστης τροποποιεί ολόκληρο το αντικείμενο), το LWW είναι πλήρως κατάλληλο και πολύ πιο απλό στην υλοποίηση.

Στην πράξη, πολλά συστήματα εφαρμόζουν υβριδική προσέγγιση: LWW για μεταπληροφορίες και πεδία ανώτερου επιπέδου, Merge για δομημένα δεδομένα. Η Firebase Firestore, για παράδειγμα, χρησιμοποιεί LWW για τις περισσότερες λειτουργίες, αλλά υποστηρίζει συναλλαγές με αισιόδοξη κλείδωση για ατομικές ενημερώσεις όταν ο πραγματοποιητής καθορίζει ρητά ότι ένα πεδίο δεν πρέπει να χαθεί κατά τη σύγκρουση.

Σύμφωνα με έρευνα πραγματοποιητών κατανεμημένων συστημάτων (Stack Overflow Survey, 2025), 54% επιλέγουν LWW για MVP και πρωτότυπα, μεταβαίνοντας σε Merge ή CRDT στη φάση κλίμακωσης. Το κλειδί κριτήριο είναι η συχνότητα συγκρούσεων: εάν λιγότερο από 1% των συνεδριών οδηγούν σε συγκρούσεις, το LWW είναι περισσότερο από αρκετό. Εάν οι συγκρούσεις επηρεάζουν περισσότερο από 5% των συνεδριών, αξίζει να επενδύσει σε Merge ή CRDT.