liveBook · Manning

Data loss

As explained in API Design Patterns

Data loss is the unintended removal or destruction of information that should have been retained.

Data loss is the unintended removal or destruction of information that should have been retained. In APIs, broad resource replacement can overwrite another client's changes or erase fields introduced by a newer resource version. section 8.1.2

Prevent data loss by:

  • Using partial updates when clients need to change only specific fields, reducing unrelated overwrites. section 8.1.2
  • Applying consistency checks or locking when concurrent operations can conflict, while recognizing that retries may still be required. section 8.1.2
  • Choosing soft deletion or a backup strategy according to regulatory requirements and whether permanent removal is acceptable. section 25.4

A stale client erases newer data

A current client adds a ChatRoom description. An older client, unaware of that field, changes only the title and replaces the whole resource. The resulting ChatRoom retains the new title but loses the description. section 8.1.2

Table 8.1 An example sequence of code run by two users that could present problems (view table figure)

User 1 API call

User 2 API call

 
let chatRoom = GetChatRoom({
  id: '1'
});
 
let chatRoom = GetChatRoom({
  id: '1'
});
 
chatRoom.title = "My Chat!";
 
let desc = fetchRandomQuote();
 
chatRoom = ReplaceChatRoom({
  chatRoom: chatRoom,
});
 
chatRoom.description = desc;
 
 
chatRoom = ReplaceChatRoom({
  chatRoom: chatRoom,
});

Compare two clients reading, modifying, and replacing the same ChatRoom to see how the final replacement discards an unrelated update. section 8.1.2

How API Design Patterns covers it

How deep it goes
Explains concurrent replacement and stale schemas through a worked ChatRoom sequence, then contrasts soft deletion with backups.
Examples
Uses concurrent ChatRoom clients and contrasts permanent deletion with backup or soft-deletion policies.
What it assumes
Assumes familiarity with API resources, standard replacement methods, concurrent clients, and resource deletion.
What you can do after
Diagnose/debug data loss by identifying stale replacements, missing consistency checks, outdated fields, or unsuitable deletion policies.
How it connects
Connects partial updates, resource replacement, consistency checks, schema evolution, soft deletion, and data backup.
Cover of API Design Patterns
liveBookmanning.com
Read API Design Patterns on liveBook Get the book at manning.com

Also explained in

Compare how 4 books explain data loss →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of API Design Patterns. The section links point to the parts of the book it draws on.