processing-api-batches

What this skill does

# Processing API Batches

## Overview

Optimize bulk API operations with batch request endpoints, parallel execution with concurrency control, partial failure handling, and progress tracking. Implement batch processing patterns that accept arrays of operations in a single request, execute them efficiently with database bulk operations, and return per-item results with individual success/failure status.

## Prerequisites

- Web framework capable of handling large request bodies (configure body size limits: 10MB+ for batch payloads)
- Database with bulk operation support (bulk insert, bulk update, transactions)
- Queue system for async batch processing: Bull/BullMQ (Node.js), Celery (Python), or SQS
- Progress tracking store (Redis) for long-running batch status polling
- Rate limiting aware of batch operations (count individual operations, not just requests)

## Instructions

1. Examine existing API endpoints using Read and Grep to identify operations frequently called in loops by consumers, which are candidates for batch equivalents.
2. Design the batch request format: accept an array of operations in the request body, each with an optional client-provided `id` for result correlation, e.g., `POST /batch` with `{operations: [{method: "POST", path: "/users", body: {...}, id: "op1"}]}`.
3. Implement synchronous batch processing for small batches (< 100 items): validate all items, execute in a database transaction, and return per-item results with `{id, status, result|error}` for each operation.
4. Add asynchronous batch processing for large batches (> 100 items): accept the batch, return 202 Accepted with a `batchId` and status polling URL, process in a background worker, and update progress in Redis.
5. Implement concurrency control: process batch items in parallel with configurable concurrency limit (default: 10) using `p-limit` or `asyncio.Semaphore` to prevent database connection exhaustion.
6. Handle partial failures: do not abort the entire batch when individual items fail; collect per-item results with success/failure status, and return the batch result with summary counts (`succeeded`, `failed`, `total`).
7. Add progress tracking for async batches: expose `GET /batch/:batchId/status` returning `{total, completed, failed, progress: 0.75, status: "processing|completed|failed"}`.
8. Implement batch size limits and validation: maximum 1000 items per batch, reject oversized batches with 413, validate all items before processing any, and return all validation errors upfront.
9. Write tests covering: small sync batches, large async batches, partial failure handling, progress tracking, concurrency limits, and batch size validation.

See `${CLAUDE_SKILL_DIR}/references/implementation.md` for the full implementation guide.

## Output

- `${CLAUDE_SKILL_DIR}/src/routes/batch.js` - Batch request endpoint with sync/async routing
- `${CLAUDE_SKILL_DIR}/src/batch/processor.js` - Batch execution engine with concurrency control
- `${CLAUDE_SKILL_DIR}/src/batch/validator.js` - Batch request validation and size limit enforcement
- `${CLAUDE_SKILL_DIR}/src/batch/progress.js` - Redis-backed progress tracking for async batches
- `${CLAUDE_SKILL_DIR}/src/batch/workers/` - Background worker for async batch processing
- `${CLAUDE_SKILL_DIR}/src/batch/results.js` - Per-item result aggregation with summary statistics
- `${CLAUDE_SKILL_DIR}/tests/batch/` - Batch processing integration tests

## Error Handling

| Error | Cause | Solution |
|-------|-------|----------|
| 413 Payload Too Large | Batch exceeds maximum item count (1000) or body size limit | Return clear error with maximum allowed count; suggest splitting into multiple batch requests |
| 207 Multi-Status | Some batch items succeeded while others failed | Return per-item status array; include error details for failed items; provide summary counts |
| 408 Batch Timeout | Synchronous batch processing exceeded request timeout | Switch to async processing for large batches; return 202 with status polling URL |
| Partial transaction failure | Database transaction rolls back all items due to one failure | Use savepoints for per-item isolation; or process items individually outside a wrapping transaction |
| Progress tracking stale | Worker crashed mid-batch; progress stops updating | Implement heartbeat monitoring; mark batch as failed after heartbeat timeout; enable retry from last checkpoint |

Refer to `${CLAUDE_SKILL_DIR}/references/errors.md` for comprehensive error patterns.

## Examples

**Bulk user import**: Accept a CSV-uploaded batch of 5000 user records via `POST /batch/users/import`, return 202 with `batchId`, process asynchronously with progress updates, and provide a downloadable results file when complete.

**Multi-resource batch**: Accept mixed operations in a single batch: `[{method:"POST",path:"/users",...}, {method:"PUT",path:"/orders/123",...}, {method:"DELETE",path:"/products/456"}]`, executing each against the appropriate handler.

**Idempotent batch retry**: Client includes `idempotencyKey` per batch item; on retry, already-completed items return their cached result without re-execution, while failed items are re-attempted.

See `${CLAUDE_SKILL_DIR}/references/examples.md` for additional examples.

## Resources

- Google Cloud batch request format: https://cloud.google.com/storage/docs/json_api/v1/how-tos/batch
- Facebook Graph API batch requests pattern
- HTTP 207 Multi-Status (WebDAV) for partial success responses
- Bull queue documentation: https://docs.bullmq.io/