Object update order guarantees

Hi,

Should we expect sequential updates to the same object in an index to be processed in sequential order by Algolia? i.e., with the JavaScript API:

index.saveObjects([{objectID: 'a1', foo: 'old'}], function(err, content) {
  index.saveObjects([{objectID: 'a1', foo: 'new'}], function(err, content) {
  });
});

Is there any conceivable scenario in which we would not expect the a1 object in this index to eventually contain the value "new" for the property foo?

We understand that a successful call to saveObjects() makes no guarantees about the index being up-to-date – only that the update task has been queued up on your end. We also understand that we must avoid sending stale updates in the first place. Our question is, given updates sent and confirmed to be added to the queue in sequential order, should we expect that Algolia will always update the index in the same order?

Thank you!

Hello @goodeggs,

Thank you for posting your question on our Discourse instance.

Regarding your question, the answer is yes, we do guarantee that sequential calls will be processed in the same order if they target the same server. If you don’t target the same server most of the time, it will, but, you can have a corner case where:

  • the 1st update is submitted to one of the three machine of the cluster;
  • the 2nd update is submitted to another machine of the cluster around the same millisecond.

In this specific configuration for instance, it may happen that updates are not performed in the expected sequential order.

I hope it helps. Don’t hesitate to reach again if my explanation isn’t clear enough.

Have a nice day,

Hi Anthony,

Thanks for the details. Could you please clarify if this is intended behavior or a bug?

Could you also please confirm that our understanding as follows is correct?

Per this page:

The primary hosts are {Application-ID}.algolia.net for write operations and {Application-ID}-dsn.algolia.net for read operations. *The -dsn host guarantees high availability through automatic load balancing and also leverages our Distributed Search Network (if you subscribed that option).

In order to guarantee a very high availability, we recommend to implement a retry strategy for all API calls on the following fallback hosts: {Application-ID}-1.algolianet.com, {Application-ID}-2.algolianet.com, {Application-ID}-3.algolianet.com.

Is this implying that the write host {Application-ID}.algolia.net does not use internal load balancing? i.e. if we want to avoid the issue you described as much as possible by always writing to the same host, would it be sufficient to configure our algolia client with an array of hosts in a fixed order rather than randomized? e.g. [{Application-ID}.algolia.net, {Application-ID}-1.algolianet.com, {Application-ID}-2.algolianet.com, {Application-ID}-3.algolianet.com. Or should we exclude {Application-ID}.algolia.net from that list because it uses load balancing internally?

(We understand that this issue could still occur in the rare case of actually falling back to another host. We would accept this in exchange for high availability.)

Thank you for your help!

Hello again,

I confirm this is intended.

No. I confirm that the {Application-ID}.algolia.net is also load balancing against the 3 machines of your cluster. For your information, {Application-ID}-dsn.algolia.net is load balancing against the 3 machines of your cluster but also against your replicas, if any. However, replicas are not capable of indexing, that’s why we are using {Application-ID}-dsn.algolia.net for reads and {Application-ID}.algolia.net for writes.

Yes, it would be enough. However, as you said afterwards, you’ll break the guarantee of high availability if the only host you’re targeting goes down.

Also, if you care more about the ordering than indexing speed, you can also wait for the indexing task to be finished between each of your saveObjects calls, but it may take a while (see the waitTask call for that).

I hope it helps. If anything isn’t clear enough, don’t hesitate to reach again, I’ll try to help. :slight_smile: