Algolia Rate-Pressure Handling
Overview
This skill avoids invented universal quotas. It distinguishes key restrictions, current contractual usage, indexing pressure, transient transport failures, and application amplification using actual response evidence.
Prerequisites
- A named repository, environment, and Algolia application or index in scope
- The local lockfile and installed client types as implementation authority
- A safe read-only query or explicitly disposable test target
- Current first-party documentation for any provider behavior that affects the change
Tool Discipline
Use Read, Glob, and Grep to inspect local code, configuration names, tests, and dependency versions. Use WebFetch only for current official Algolia documentation. Use Write or Edit only after identifying the target files, constraints, and verification plan.
Current Contract
- Interpret a 429 from its status, message, operation, request ID, and current account terms.
- Inspect installed client behavior before layering application retries on top of SDK host retry.
- Bound attempts, elapsed time, concurrency, and queue depth; retry only operations whose semantics are safe.
- Protect interactive search from batch indexing through workload scheduling and backpressure.
Authentication
Use operation-specific, least-privilege keys. Never raise limits by replacing a restricted key with an Admin key or by removing tenant safeguards.
Instructions
- Capture the failing operation, response, request ID, client version, concurrency, queue depth, and traffic source.
- Check key restrictions and current usage or contract evidence without assuming a fixed quota.
- Identify amplification from duplicate clients, unbounded concurrency, retries, bots, or oversized batches.
- Define a retry budget with eligible errors, maximum attempts, elapsed timeout, jitter, and cancellation.
- Apply concurrency limits or scheduling at the producer and test partial failure and shutdown.
- Verify search health, queue recovery, idempotency, and alerting under controlled pressure.
Approval Boundaries
Do not load-test production, remove rate restrictions, increase plan limits, or retry non-idempotent work without owner approval.
Output
Return the observed limit evidence, pressure source, retry and queue policy, test results, residual capacity risk, and any commercial decision requiring an account owner.
Error Handling
| Condition | Response |
|---|---|
| 429 message ambiguous | Retain request ID and consult current provider support or docs. |
| Retry storm begins | Open the circuit and drain or shed work. |
| Queue exceeds bound | Stop producers and preserve work for controlled replay. |
| Plan change proposed | Separate the commercial approval from the technical fix. |
Examples
Use this compact input and expected handoff to calibrate scope and evidence quality.
Input:
operation=saveObjects; status=429; concurrency=40; sdk=5.59.0
Expected handoff:
cause=producer-amplification; concurrency=4; retry-budget=bounded; recovery=verified