I have a RabbitMQ broker, on which I post different messages that will end up as documents in Elasticsearch. There are multiple consumers from the broker, which are actually different threads in a task executor assigned to an amqp inbound gateway (using spring integration and spring amqp here).

Think at the following scenario: I have created a doc in ES with the structure

```
{
   "field1" : "value1",
   "field2" : "value2"
}

```

Afterwards I send two update requests, both updating the same field, let's say `field1`. If I send this messages one right after another(common use case in production), my consumer threads will fetch the messages in the right order(amqp allows this), but the processing could happen in the wrong order and the later updated value could be overwritten by the first one. I will end up having wring data.

How can I make sure my data won't get corrupted? =>Having 1 single consumer thread is not enough, because if I want to scale out by adding more machines with my consuming app, I will still end up having multiple consumers. I might need ordering of messages, but having multiple machines I will probably need to create some sort of a cluster aware component, I am using SI, so this seems really hard to do in my opinion. 

In pre 1.2 versions of ES, we used an external version, like a timestamp, and ES would have thrown `VersionConflictException` in my scenario:first update would have had version 10000 let's say, the second 10001 and if the first would have been processed first, ES would reject the request with version 10000 as it's lower than the existing one. But from the latest versions, ES guys [have removed this functionality](https://github.com/elasticsearch/elasticsearch/issues/5661) for update operations.