Intro

IT systems mostly exist in the 'last write wins' (LWW) world. This approach has its own advantages, particularly due to its simplicity. However, that doesn't mean it is the best method in all cases. Sometimes, it's necessary to prevent data loss or to ensure that our changes are made based on the version of the data that client intended to change.

Problem

The crux of the matter is not the loss of the "Hello Me" update, but rather the fact that the server accepted the "Hello World" update from Client A, even though the change was based on outdated data. This might be tolerable when dealing with simple text, but what if the update pertains to more complex structures, like graphs? This could potentially lead to problems with broken structures.

Solution

To avoid issues with data integrity, we can use ETag as a marker of the resource version that the client is interacting with. Let's consider how this works using the following simplified scheme:

In this scheme, the server does not accept the change from Client A, because the ETag it sends is older than the one the server holds (the ETag was updated after Client B's PUT operation).

This solution does present another issue: what should we do with the update that Client A is attempting to send? The answer depends on the type of client. If the client is a human, we can display an error message and the resolution will depend on the user experience (UX) flow. If the client is a worker or another server, we can retry the entire operation with the updated version of the resource (simply get the new version and try again).

In what other scenarios can ETag be useful?

• Data Consistency: For example, when you retrieve data in sequential pages or ranges and need to ensure that the data hasn't changed between requests.
• Data Caching: For instance, the client holds the ETag and sends a HEAD request to verify whether the resource has changed or not (and can retrieve the updated version if needed).

Links

• ETag