> ## Documentation Index
> Fetch the complete documentation index at: https://algolia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Handling concurrency with versioning

> Learn how to use versioning and optimistic locking in your indexing pipeline to guarantee data consistency, even in concurrent environments.

export const Records = () => <Tooltip tip="A record is a searchable object in an Algolia index. Each record consists of named attributes." cta="Algolia records" href="/doc/guides/sending-and-managing-data/prepare-your-data#algolia-records">
    records
  </Tooltip>;

export const Index = () => <Tooltip tip="An Algolia index is a searchable dataset that consists of records and configuration settings. These settings define how the records are searched and ranked.">
    index
  </Tooltip>;

If you have multiple indexing processes running, one process could try to update a record at the same time as another.
If this happens, your <Records /> might turn out differently than expected.

If you have an ecommerce website, and your backend runs two processes to index its changes to Algolia with the [`partialUpdateObjects`](/doc/libraries/sdk/v1/methods/partial-update-objects) method.
One process sends an update to set the stock of a product from `10` to `20`, because you just received ten new items in a shipment.
Simultaneously, another process sets the stock for this product from `10` to `9` because of an order that just came in.

Depending on which job wins the race condition, the stock is now either `9` or `20`, even though the correct stock is `19`.

## Versioning

One way to handle concurrency is the [`IncrementSet`](/doc/libraries/sdk/v1/methods/partial-update-objects#update-only-if-the-value-is-greater-than-a-numeric-attribute) [operation](/doc/libraries/sdk/v1/methods/partial-update-objects#built-in-operations).
It lets you update a record only if you provide a higher numerical value than already exists in the record,
or a value higher than 0 if the record doesn't exist.

A great use-case for this is adding a Unix timestamp to your records.
With [`IncrementSet`](/doc/libraries/sdk/v1/methods/partial-update-objects#update-only-if-the-value-is-greater-than-a-numeric-attribute),
Algolia only updates your record if the timestamp you sent is more recent than the existing one.
If you update in the meantime,
you prevent Algolia from overriding your record:
**only the latest update is taken into account**.

## Optimistic locking

Another way to handle concurrency is with the [`IncrementFrom`](/doc/libraries/sdk/v1/methods/partial-update-objects#update-only-if-the-value-matches-a-numeric-attribute) [operation](/doc/libraries/sdk/v1/methods/partial-update-objects#built-in-operations).
It lets you update a record only if you provide the current version of that record, or 0 if the record doesn't exist.

A typical use-case is when you perform a read-modify-write sequence:

1. Read a record from your <Index />.
2. Make the changes you want to make.
3. Provide the [`IncrementFrom`](/doc/libraries/sdk/v1/methods/partial-update-objects#update-only-if-the-value-matches-a-numeric-attribute) operation with the old value of your versioning attribute.

With this approach, Algolia only updates your record if the value from your [`IncrementFrom`](/doc/libraries/sdk/v1/methods/partial-update-objects#update-only-if-the-value-matches-a-numeric-attribute) operation matches the current value currently in the record,
and increments it.
**If another process incremented this value in the meantime, Algolia ignores the update.**

<Note>
  Algolia doesn't provide feedback when it rejects an update because of versioning or optimistic locking.
  You have to wait for the indexing operation to complete,
  then fetch the record to compare it to the desired result.
  An ignored operation won't necessarily show up as published with the [`waitTask`](/doc/libraries/sdk/v1/methods/wait-task) API method.
</Note>
