Modern applications live in a messy world.<\/p>\n\n\n\n
Users go offline. Networks lie. Devices crash. Two people edit the same record at the same time. Files are uploaded halfway and then abandoned. Yet expectations are brutal: the app must feel instant, never lose data, and always recover<\/em>.<\/p>\n\n\n\n This post describes TS\u2011LWW Sync<\/strong> (Timestamped Last\u2011Writer\u2011Wins Sync), a synchronization algorithm designed for real-world CRUD applications \u2014 especially offline\u2011first systems like a dental clinic CRM (Apexo)<\/strong> \u2014 where correctness, speed, and simplicity matter more than academic perfection.<\/p>\n\n\n\n The goal of TS\u2011LWW Sync is not to be clever. TS\u2011LWW Sync is built on one simple observation:<\/p>\n\n\n\n If every change has a timestamp, then synchronization can be reduced to “what changed after time X”<\/em>.<\/p>\n<\/blockquote>\n\n\n\n Instead of tracking per\u2011record versions, diffs, or complex merge trees, the system tracks:<\/p>\n\n\n\n Everything else falls out naturally.<\/p>\n\n\n\n TS\u2011LWW Sync<\/strong> stands for:<\/p>\n\n\n\n It is best described as a:<\/p>\n\n\n\n Store\u2011versioned, timestamp\u2011driven, offline\u2011first synchronization algorithm with deferred writes.<\/em><\/p>\n<\/blockquote>\n\n\n\n Instead of versioning every record individually, the system keeps one version number for the entire dataset<\/strong>:<\/p>\n\n\n\n This allows the client to ask a very cheap question:<\/p>\n\n\n\n \u201cGive me everything that changed after version X.\u201d<\/p>\n<\/blockquote>\n\n\n\n No scans. No diffs. No reconciliation passes.<\/p>\n\n\n\n All user actions are applied locally first<\/strong>:<\/p>\n\n\n\n If the network is available, the system attempts<\/em> to push immediately. From the user\u2019s perspective:<\/p>\n\n\n\n The app never blocks. Ever.<\/p>\n<\/blockquote>\n\n\n\n When offline, changes are placed into a deferred queue<\/strong>:<\/p>\n\n\n\n This queue acts as a lightweight write\u2011ahead log<\/strong>.<\/p>\n\n\n\n When connectivity returns, deferred changes are replayed deterministically.<\/p>\n\n\n\n During synchronization:<\/p>\n\n\n\n Conflict rule:<\/p>\n\n\n\n Whichever side has the newer timestamp wins<\/strong><\/p>\n<\/blockquote>\n\n\n\n No heuristics. No guessing. No silent corruption.<\/p>\n\n\n\n Conflicts are counted, observable, and predictable.<\/p>\n\n\n\n Binary files (images, documents) are not treated as records<\/strong>.<\/p>\n\n\n\n Instead, they are handled as:<\/p>\n\n\n\n This avoids the most common sync bug in business apps:<\/p>\n\n\n\n “The data synced, but the images didn\u2019t.”<\/em><\/p>\n<\/blockquote>\n\n\n\n Realtime updates do not<\/strong> push data directly.<\/p>\n\n\n\n They simply say:<\/p>\n\n\n\n \u201cSomething changed \u2014 you might want to sync.\u201d<\/p>\n<\/blockquote>\n\n\n\n This keeps the system robust even when realtime messages are dropped, duplicated, or delayed.<\/p>\n\n\n\n Sync work is O(changes)<\/strong>, not O(total records)<\/strong>.<\/p>\n\n\n\n In idle state, CPU usage is effectively zero.<\/p>\n\n\n\n TS\u2011LWW Sync is extremely network\u2011efficient:<\/p>\n\n\n\n Typical sync payloads are tiny<\/strong>, even with large datasets.<\/p>\n\n\n\n This makes it ideal for:<\/p>\n\n\n\n Memory usage scales linearly with current data size, not edit history.<\/p>\n\n\n\n A dentist edits multiple patient records while offline.<\/p>\n\n\n\n When connectivity returns, everything syncs automatically.<\/p>\n\n\n\n No lost work. No manual recovery.<\/p>\n\n\n\n Result:<\/p>\n\n\n\n Predictable. Transparent. Debbugable.<\/p>\n\n\n\n The image operation is retried independently. Dental clinic systems have unique requirements:<\/p>\n\n\n\n TS\u2011LWW Sync is a natural fit because:<\/p>\n\n\n\n In practice, the system feels:<\/p>\n\n\n\n Instant when offline, invisible when online.<\/em><\/p>\n<\/blockquote>\n\n\n\n And that\u2019s a feature<\/strong>, not a limitation.<\/p>\n\n\n\n TS\u2011LWW Sync embraces a simple truth:<\/p>\n\n\n\n Most business apps do not need perfect merges. By choosing store\u2011level versioning, timestamp\u2011based pulls, and deferred writes, this algorithm delivers exactly that \u2014 without complexity tax.<\/p>\n\n\n\n For systems like Apexo<\/strong>, where real people rely on real data every day, this approach keeps the focus where it belongs:<\/p>\n\n\n\n on the work \u2014 not on the sync.<\/strong><\/p>\n\n\n\n If you\u2019re building an offline\u2011first business application and want a sync system that behaves like a calm adult instead of a fragile genius, TS\u2011LWW Sync is worth considering.<\/em><\/p>\n\n\n\n This synchronization algorithm is designed for offline-first applications<\/strong> where multiple clients may modify the same data independently and then reconnect later. The core goals are:<\/p>\n\n\n\n At a high level, each record carries versioning metadata<\/strong> that allows the system to decide which change should win when conflicts occur.<\/p>\n\n\n\n Each record has an This timestamp is the primary comparison tool during synchronization.<\/p>\n\n\n\n Every client or store has a unique This guarantees that:<\/p>\n\n\n\n When syncing two versions of the same record:<\/p>\n\n\n\n This creates a total ordering<\/strong> across all updates, which is crucial for convergence.<\/p>\n\n\n\n Instead of physically deleting records, the algorithm uses a This makes deletion sync-safe and reversible<\/strong>.<\/p>\n\n\n\n Rather than syncing the entire dataset every time, each client tracks the last known sync point per store<\/strong>.<\/p>\n\n\n\n During sync:<\/p>\n\n\n\n Because conflict resolution is:<\/p>\n\n\n\n All replicas will eventually converge to the same state, regardless of sync order or frequency.<\/p>\n\n\n\n Modern applications live in a messy world. Users go offline. Networks lie. Devices crash. Two people edit the same record at the same time. Files are uploaded halfway and then abandoned. Yet expectations are brutal: the app must feel instant, never lose data, and always recover. This post describes TS\u2011LWW Sync (Timestamped Last\u2011Writer\u2011Wins Sync), a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-21","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.apexo.app\/index.php?rest_route=\/wp\/v2\/posts\/21","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.apexo.app\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.apexo.app\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.apexo.app\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.apexo.app\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=21"}],"version-history":[{"count":3,"href":"https:\/\/blog.apexo.app\/index.php?rest_route=\/wp\/v2\/posts\/21\/revisions"}],"predecessor-version":[{"id":24,"href":"https:\/\/blog.apexo.app\/index.php?rest_route=\/wp\/v2\/posts\/21\/revisions\/24"}],"wp:attachment":[{"href":"https:\/\/blog.apexo.app\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.apexo.app\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.apexo.app\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
The goal is to be reliable, fast, cheap, and understandable<\/strong>.<\/p>\n\n\n\n\n\n\n\n
\n\n\n\nThe Core Idea<\/h2>\n\n\n\n
\n
\n
\n\n\n\nNaming the Algorithm<\/h2>\n\n\n\n
\n
\n
\n\n\n\nHow It Works (Conceptually)<\/h2>\n\n\n\n
1. Store\u2011Level Versioning<\/h3>\n\n\n\n
\n
\n
\n\n\n\n2. Local\u2011First Writes<\/h3>\n\n\n\n
\n
If not, the change is safely deferred.<\/p>\n\n\n\n\n
\n\n\n\n3. Deferred Queue (Offline Engine)<\/h3>\n\n\n\n
\n
\n\n\n\n4. Pull\u2011Then\u2011Resolve Sync<\/h3>\n\n\n\n
\n
\n
\n\n\n\n5. Files Are First\u2011Class Citizens<\/h3>\n\n\n\n
\n
\n
\n\n\n\n6. Realtime Is a Signal, Not a Transport<\/h3>\n\n\n\n
\n
\n\n\n\nWhy This Is Fast<\/h2>\n\n\n\n
CPU Usage<\/h3>\n\n\n\n
\n
\n\n\n\nNetwork Usage<\/h3>\n\n\n\n
\n
\n
\n\n\n\nMemory Footprint<\/h3>\n\n\n\n
\n
\n\n\n\nReal\u2011World Scenarios<\/h2>\n\n\n\n
Scenario 1: Dentist Goes Offline<\/h3>\n\n\n\n
\n
\n\n\n\nScenario 2: Two Assistants Edit the Same Patient<\/h3>\n\n\n\n
\n
\n
\n\n\n\nScenario 3: Image Upload Fails Midway<\/h3>\n\n\n\n
\n
No corrupted state.
No dangling references.<\/p>\n\n\n\n
\n\n\n\nWhy This Fits a Dental Clinic CRM (Apexo)<\/h2>\n\n\n\n
\n
\n
\n
\n\n\n\nWhat This Algorithm Is (and Isn\u2019t)<\/h2>\n\n\n\n
It Is:<\/h3>\n\n\n\n
\n
It Is Not:<\/h3>\n\n\n\n
\n
\n\n\n\nFinal Thoughts<\/h2>\n\n\n\n
\n
They need reliability, speed, and clarity<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nHow the synchronization algorithm works (conceptual overview)<\/h2>\n\n\n\n
\n
1. Logical versioning (timestamp-based)<\/h3>\n\n\n\n
updated<\/code> value that represents the logical time of the last modification<\/strong>. This is not meant to be a perfect wall-clock time; it is simply a monotonic value that increases whenever the record is modified.<\/p>\n\n\n\n2. Store identity (tie-breaker)<\/h3>\n\n\n\n
storeId<\/code>. When two records have the same logical timestamp<\/strong>, the storeId<\/code> is used as a deterministic tie-breaker.<\/p>\n\n\n\n\n
3. Last-write-wins with deterministic ordering<\/h3>\n\n\n\n
\n
updated<\/code><\/li>\n\n\n\nstoreId<\/code><\/li>\n\n\n\nstoreId<\/code> wins<\/li>\n<\/ol>\n\n\n\n4. Soft deletes (tombstones)<\/h3>\n\n\n\n
deleted<\/code> flag.<\/p>\n\n\n\n\n
5. Incremental synchronization<\/h3>\n\n\n\n
\n
6. Convergence guarantee<\/h3>\n\n\n\n
\n
\n","protected":false},"excerpt":{"rendered":"