Home / Blog / Article
Backend Engineering · Aug 11, 2026
Cloud Save Architecture: Handling Conflict Resolution Across Devices
Cloud save sounds like a solved problem until a player opens the game on their tablet, plays for twenty minutes, then opens it on their phone before the tablet session ever synced. Now two divergent save states exist for one player, and whichever naive resolution strategy you picked, last-write-wins, first-write-wins, is about to either destroy real progress or silently ignore it. This is the conflict resolution architecture that actually holds up across real multi-device player behavior.
Why Last-Write-Wins Is Not A Strategy
Last-write-wins is not a conflict resolution strategy, it is the absence of one, and it is the default almost every naive cloud save implementation ships with because it requires no additional logic beyond a timestamp comparison. The problem surfaces the first time a player has poor connectivity on one device: their tablet session saves locally, fails to sync due to a dropped connection, and by the time it does sync an hour later, their phone session with less playtime has already overwritten the server state with a more recent timestamp. The tablet progress is gone, permanently, and the player has no way to know it happened until they notice their character level dropped.
Modeling Save Data As Mergeable Deltas, Not Snapshots
The architectural shift that actually solves this is moving away from whole-state snapshot saves toward append-only deltas: instead of overwriting a player’s entire save state, each device submits a log of discrete changes, items acquired, currency earned, levels completed, since its last successful sync. Two devices that both played offline can have their delta logs merged rather than compared as competing whole-state snapshots, because most game progress, currency earned, items collected, levels completed, is naturally additive and does not actually conflict even when it happened on two different devices during the same window.
What Genuinely Conflicts Versus What Merges Automatically
Not everything in a save state is safely mergeable, and the design work is correctly classifying each data type. Additive values, currency, XP, completed level flags, merge automatically: if two devices both report gold earned, the totals sum. Singleton state, the player’s currently equipped loadout, their last selected difficulty, genuinely conflicts and needs an explicit resolution rule, we default to most-recent-successful-sync for pure preference state since the stakes of getting it wrong are low. The category that demands the most care is limited or unique resources, a single-use item, a name change token, where merging incorrectly could duplicate something that was only supposed to exist once.
Idempotent Sync Operations
A sync operation that is not idempotent turns a simple network retry into a duplication bug: a client submits a delta, the server processes it and grants the rewards, but the response is lost to a dropped connection, so the client retries the same submission, and now the player has been credited twice for one play session. Every delta submission carries a client-generated unique ID, and the server maintains a short-term log of processed IDs specifically to detect and silently discard exact retries before they are applied a second time, the same idempotency pattern that protects battle pass reward claims from duplication.
Conflict Surfacing: When To Ask The Player
Some conflicts genuinely cannot be resolved automatically without risking a decision the player would disagree with, and the honest answer in those cases is to surface the conflict rather than silently guess. If two devices report meaningfully divergent progress that automated merge rules cannot reconcile confidently, we present the player a choice on next login: keep this device’s progress, or the other device’s, with a clear summary of what each option contains. This happens rarely if the merge rules above are well designed, but having the fallback path built and tested means a genuinely ambiguous conflict degrades to a player decision instead of an engineering guess that might be wrong.
Offline-First Design As The Default Assumption
The architecture above only works if the client is built offline-first from the start: every action writes to local state immediately and queues for sync, rather than treating the network call as the source of truth the player has to wait on. Games retrofitted from an online-first assumption tend to have gameplay logic scattered with implicit dependencies on an immediate server response, which makes adding proper offline queuing and delta-based sync a much larger undertaking than building it in from day one. We treat offline-first as a foundational architecture decision made before the first line of save logic is written, not a resilience feature bolted on after a live incident forces the issue.
A Cloud Save Architecture Checklist
Before trusting a cloud save system with real player progress across devices, confirm: save data is modeled as append-only deltas, not whole-state snapshot overwrites; every data field is explicitly classified as additive, singleton, or unique-resource, with a defined merge rule for each; every sync operation carries a unique ID and is verifiably idempotent against retry; a player-facing conflict resolution flow exists and has been tested for the cases automated merging cannot confidently resolve; and the client was built offline-first, writing local state immediately rather than blocking on server confirmation. Systems built this way survive real-world multi-device usage, spotty hotel WiFi, airplane mode sessions, two tablets in one household, without a single lost-progress support ticket. Systems built on last-write-wins usually generate their first one within the opening week of live traffic.
Keep Reading
More from the blog
Want these insights on your build?
The engineers writing these articles are the ones who would work on your game.