FAQ / Indexing / Is there a rate limit?

Whenever a server starts being overloaded, Algolia first delays then rejects indexing operations if necessary. These proactive measures aim at avoiding downtime. This is called the ‘rate limit’.

The introduced delay (or throttling) exists to avoid reaching the rejection limit. Algolia keeps throttling or rejecting operations until the server comes back to a more manageable state.

It’s important to note that:

When’s the rate limit triggered?

Algolia’s servers are designed to contain large amounts of data and to perform fast search and indexing operations. Therefore, it’s unlikely (but not impossible) to reach the natural limits of a server.

To avoid downtime or delay, every Algolia server has an internal “rate limit” mechanism that is designed to stop overloading the server with too many costly indexing operations.

Overloading happens when the server can no longer handle indexing operations within a reasonable time frame. Algolia monitors the servers to avoid the following scenarios:

  • A client’s overall application size (the total of all index sizes) becomes too large.
  • Old requests remain unprocessed, indicating a backlog of indexing requests.
  • The indexing queue has too many unprocessed requests, or the total size of queued requests is too big.

Aside from these scenarios, the following indexing operations are throttled and rate-limited because they’re computationally expensive: deleteBy, clearIndex, moveIndex.

Regarding these indexing operations:

  • When you have more than 100 pending requests, your requests are throttled.
  • When you have more than 5000 pending requests, any new request are ignored and an HTTP 429 error is returned.

The specific limits for application size, request age, and indexing queue size depend on your plan. If your plan includes dedicated infrastructure, contact your success team to discuss the rate limits on your cluster.

What happens when the rate limit is reached?

If any of these scenarios occur, Algolia starts slowing down incoming indexing operations, and the client needs to wait before sending new requests. This delay is mostly transparent.

Throttling of operations varies depending on their type. Index operations (clearIndex, moveIndex, copyIndex, setSettings, deleteBy) are subject to stricter rules than record operations (saveObjects, partialUpdateObjects, saveRule, saveSynonym).

If the server continues to be overloaded despite throttling, it starts to reject indexing requests as they come in, returning an HTTP 429 error. The error message gives more details about the cause of rejection.

The Rate limit reached for file size error message indicates that your overall application size is too large. In this case, you must remove some records or indices to continue sending updates. When you reach this rate limit, delete operations are still permitted. For all other limits, it’s best to wait for the servers to catch up before sending any further indexing requests.

Did you find this page helpful?