If you have 2 or more instances of Kibana sharing the same .kibana index, they can clobber each other's changes with values they have in cache.

To Reproduce;

1. Start 2 instances of Kibana either on different machines or on different ports. I'm running #1 on port 5601 and #2 on port 5602 on the same machine.
2. Go to Settings > Advanced on both instances
3. on #1 change discover:sampleSize (Default: 500) to 499
4. on #2 change discover:sampleSize (Default: 500) to 501
5. on #1 change courier:maxSegmentCount (Default: 30) to 29
6. refresh both instances, and/or check the config object http://localhost:9200/.kibana/config/_search

Expected discover:sampleSize (Default: 500) to be 501 since it was the last change made to that setting.

Actual discover:sampleSize (Default: 500) to 499 (probably because #1 had 499 cached when it wrote the courier:maxSegmentCount so it wrote the whole config object)

If possible, it should know the version of the config object it has cached.

When it tries to write the object it should check the version first and, if later, show the user an error if it is a later version, and refresh the page to show the current version. The user can try to save again, or has to make their change again and save again.

OR

When it tries to write the object it should check the version first and, if later, get the latest version and re-apply the change and try to save it again (again checking the version).

OR

When it tries to write the object the write should include the next version and fail if that version already exist in Elasticsearch? Not sure which of these functionalities is possible. Then handle the error by getting the latest version, and re-applying the change. This could be the best performing solution because it only takes one round-trip in most cases.