High-throughput embedding is a flow-control problem. Batch within provider and model limits, cap concurrency, classify retryable failures, respect retry hints, add exponential backoff with jitter, and propagate backpressure when downstream capacity falls. Measure queue age, tokens, calls, errors, latency, and cost so a source burst cannot overwhelm the provider or PostgreSQL.
Limits can apply per request, input, token count, minute, account, region, model, connection, or database write rate. Model them as configuration obtained from approved documentation—not constants guessed by the worker.
Batching improves throughput but increases the retry blast radius and per-request latency. Assign each item its own identity and outcome even when the provider accepts a batch.
Never retry authentication, invalid dimensions, prohibited content, or oversized inputs without a state change.
Workers reduce intake when queue age, provider throttles, database commit latency, replica/WAL pressure, or error budgets exceed thresholds. Source connectors may pause, sample, or prioritize critical tenants under an explicit policy. Dropping work silently is not backpressure.
Use a fake provider that returns success, throttling, timeout, partial failure, and invalid input deterministically. Load-test below and above quota. Assert maximum concurrent calls, retry count, queue-age recovery, database write rate, and that terminal errors do not retry.
Given these provider quotas, batch rules, workload arrival rates, and database capacity [paste], propose a flow-control policy. Include batch sizing, concurrency, fairness, retry matrix, jitter, circuit-breaker states, queue-age SLO, and a load-test table.
Verification contract: A deterministic simulator must show bounded concurrency and eventual recovery without exceeding retry or cost budgets.