---
title: "How do you handle timestamp/versioning to detect stale data in the IndexedDB cache?"  
description: "How do you handle timestamp/versioning to detect stale data in the IndexedDB cache?"  
author: "ICSM Computer"  
published: 2025-07-10  
updated: 2025-07-10  
canonical: https://www.mindstick.com/interview/34331/how-do-you-handle-timestamp-versioning-to-detect-stale-data-in-the-indexeddb-cache  
category: "IndexedDB"  
tags: ["database", "indexeddb"]  
reading_time: 4 minutes  

---

# How do you handle timestamp/versioning to detect stale data in the IndexedDB cache?

To detect **stale data in** [**IndexedDB**](https://www.mindstick.com/interview/34289/what-is-indexeddb) during synchronization with a remote server, the most common and reliable technique is to use **timestamps or versioning** metadata on each record. Here’s how to handle it effectively:

### 1. Add a `lastModified` or `version` Field per Record

Every record stored in IndexedDB and on the server should include one of:

- `lastModified`: A UTC timestamp (e.g., ISO 8601 or Unix Epoch).
- `version`: A monotonically increasing number (e.g., `int` or `UUID`/`ETag`).

#### Example Record:

```plaintext
{
  id: "task_123",
  title: "Buy milk",
  completed: false,
  lastModified: "2025-07-11T04:32:12.000Z"  // ISO timestamp
}
```

### 2. Compare Timestamps during Sync

During sync:

- Fetch latest server records (with their `lastModified` or `version`).
- Compare with the corresponding IndexedDB record.
- If the local version is **older**, update from the server.
- If the local version is **newer**, push to server.
- If both changed, trigger **conflict resolution**.

#### Example (timestamp comparison):

```javascript
if (local.lastModified < server.lastModified) {
    // Update local IndexedDB with server data
} else if (local.lastModified > server.lastModified) {
    // Push local changes to server
} else {
    // Data is in sync – no action needed
}
```

### 3. Batch [Versioning](https://www.mindstick.com/interview/34310/how-do-you-handle-version-changes-in-indexeddb) for Sync Tokens

If you want to track updates more efficiently:

- Maintain a **global lastSyncTimestamp**.
- During sync, fetch records from the server with `lastModified > lastSyncTimestamp`.
- Apply changes and update local IndexedDB.
- Then update `lastSyncTimestamp`.

### 4. Handle Clock Skew (if using timestamps)

- Rely on **server-generated timestamps** whenever possible.
- On client-side creation, mark them as “pending” until server confirmation.

### 5. Optional: Use Hashing for Change Detection

For large documents:

- Generate a hash (e.g., SHA-256) of the content.
- Store this alongside the record and compare it during sync.
- More accurate than timestamps alone.

### [Dexie.js Example](https://www.mindstick.com/interview/34328/how-would-you-limit-memory-use-when-paginating-a-large-object-store-result-set)

```javascript
// Schema
db.tasks = new Dexie.Table("tasks", "++id, title, lastModified");

// Update with server data if newer
if (new Date(serverTask.lastModified) > new Date(localTask.lastModified)) {
    await db.tasks.put(serverTask);
}
```

### Summary

| Field | Purpose | Format |
| --- | --- | --- |
| `lastModified` | Detect stale updates | ISO Date or Unix Timestamp |
| `version` | Optional alternative to timestamps | Integer or UUID |
| `syncStatus` | Optional (e.g., `pending`, `synced`, `conflict`) | String |

## Answers

### Answer by ICSM Computer

To detect **stale data in** [**IndexedDB**](https://www.mindstick.com/interview/34289/what-is-indexeddb) during synchronization with a remote server, the most common and reliable technique is to use **timestamps or versioning** metadata on each record. Here’s how to handle it effectively:

### 1. Add a `lastModified` or `version` Field per Record

Every record stored in IndexedDB and on the server should include one of:

- `lastModified`: A UTC timestamp (e.g., ISO 8601 or Unix Epoch).
- `version`: A monotonically increasing number (e.g., `int` or `UUID`/`ETag`).

#### Example Record:

```plaintext
{
  id: "task_123",
  title: "Buy milk",
  completed: false,
  lastModified: "2025-07-11T04:32:12.000Z"  // ISO timestamp
}
```

### 2. Compare Timestamps during Sync

During sync:

- Fetch latest server records (with their `lastModified` or `version`).
- Compare with the corresponding IndexedDB record.
- If the local version is **older**, update from the server.
- If the local version is **newer**, push to server.
- If both changed, trigger **conflict resolution**.

#### Example (timestamp comparison):

```javascript
if (local.lastModified < server.lastModified) {
    // Update local IndexedDB with server data
} else if (local.lastModified > server.lastModified) {
    // Push local changes to server
} else {
    // Data is in sync – no action needed
}
```

### 3. Batch [Versioning](https://www.mindstick.com/interview/34310/how-do-you-handle-version-changes-in-indexeddb) for Sync Tokens

If you want to track updates more efficiently:

- Maintain a **global lastSyncTimestamp**.
- During sync, fetch records from the server with `lastModified > lastSyncTimestamp`.
- Apply changes and update local IndexedDB.
- Then update `lastSyncTimestamp`.

### 4. Handle Clock Skew (if using timestamps)

- Rely on **server-generated timestamps** whenever possible.
- On client-side creation, mark them as “pending” until server confirmation.

### 5. Optional: Use Hashing for Change Detection

For large documents:

- Generate a hash (e.g., SHA-256) of the content.
- Store this alongside the record and compare it during sync.
- More accurate than timestamps alone.

### [Dexie.js Example](https://www.mindstick.com/interview/34328/how-would-you-limit-memory-use-when-paginating-a-large-object-store-result-set)

```javascript
// Schema
db.tasks = new Dexie.Table("tasks", "++id, title, lastModified");

// Update with server data if newer
if (new Date(serverTask.lastModified) > new Date(localTask.lastModified)) {
    await db.tasks.put(serverTask);
}
```

### Summary

| Field | Purpose | Format |
| --- | --- | --- |
| `lastModified` | Detect stale updates | ISO Date or Unix Timestamp |
| `version` | Optional alternative to timestamps | Integer or UUID |
| `syncStatus` | Optional (e.g., `pending`, `synced`, `conflict`) | String |


---

Original Source: https://www.mindstick.com/interview/34331/how-do-you-handle-timestamp-versioning-to-detect-stale-data-in-the-indexeddb-cache

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.