The "Sync" Nightmare
In our previous breakdown, we discussed how to build a true offline-first Flutter application using a local SQLite database and a background sync engine. That is the easy part.
The hardest problem in mobile architecture begins the moment your background sync engine tries to push data to the server. It is a problem called Data Conflict.
Imagine a B2B inventory app. Worker A is in the warehouse (offline) and updates the stock of "Laptops" from 10 to 8. Worker B is in the office (online) and updates the same "Laptops" stock from 10 to 15. When Worker A walks outside and their phone reconnects to 5G, their app tries to sync. Whose data is correct?
Why Standard APIs Fail
If you use a standard REST API (UPDATE inventory SET stock = 8 WHERE id = 1), Worker A's phone will blindly overwrite Worker B's data. You have just caused silent data loss, the most unforgivable sin in enterprise software.
To solve this, your Laravel backend cannot be a simple data dump. It must act as a Conflict Resolution Engine.
Strategy 1: Last-Write-Wins (Timestamp Merging)
The most common architectural pattern for handling this is "Last-Write-Wins" using strict timestamps. Every single row in your local Flutter database and your Laravel database must carry an updated_at timestamp.
When the Flutter app sends the sync payload, it includes its local timestamp. The Laravel controller compares the timestamps before saving:
public function syncInventory(Request $request)
{
$serverItem = Inventory::find($request->id);
$clientTimestamp = Carbon::parse($request->updated_at);
// If the server data is newer than the incoming offline data, reject the update!
if ($serverItem->updated_at->gt($clientTimestamp)) {
return response()->json([
'status' => 'conflict',
'server_data' => $serverItem
], 409);
}
// Otherwise, it is safe to overwrite
$serverItem->update($request->all());
return response()->json(['status' => 'success']);
}
Handling the 409 Conflict
When Laravel returns the 409 Conflict status, the Flutter app must catch it. The background sync engine then takes the server_data returned by the API and silently overwrites the outdated local database on the phone.
Conclusion
Building an offline app isn't just about caching data; it is about managing the chaos of distributed systems. By enforcing strict timestamp-based conflict resolution, you guarantee data integrity across hundreds of disconnected mobile devices.