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. We call this action the rate limit.
The introduced delay (or throttling) exists to ensure you never reach the rejection limit. We keep on throttling or rejecting operations until the server comes back to a more manageable state.
It’s important to note that:
- The rate limit doesn’t slow down or impact in any way search operations.
- When rejecting an indexing operation, the API returns an HTTP 429 error with a message specifying the exact reason (too many jobs, job queue too large, old jobs on the queue, disk almost full).
- This limit impacts the following indexing methods: batch, saveObjects, partialUpdateObjects, deleteBy (but not deleteObjects), moveIndex, copyIndex, saveRule, setSettings, and saveSynonym.
The Algolia servers are designed to contain large amounts of data and to perform fast indexing and search operations. It is, therefore, 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. We monitor our 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.
If any of these scenarios occur, we start slowing down incoming indexing operations, and the client needs to wait before sending new requests. This delay is mostly transparent. However, if the server keeps on being overloaded, it starts to reject indexing requests as they come in, returning the HTTP 429 error mentioned above.
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).