@madmmas
· blog

Building Concurrent Ai Pipelines In Go · Part 14

Part 13 added retries for when the provider returns 429. Part 14 prevents the 429 from happening in the first place — a token bucket rate limiter that caps outgoing LLM calls per second, regardless of how many workers are running.

Building Concurrent Ai Pipelines In Go · Part 13

Part 12 showed how to cancel sibling tasks on first failure. Part 13 shows what to do next: retry with exponential backoff and jitter, distinguish retryable from permanent errors, and route exhausted articles to a dead letter queue.

Building Concurrent Ai Pipelines In Go · Part 12

Part 10 fanned out tasks and collected results. Part 12 adds the missing piece: when one task fails, cancel the rest immediately. errgroup does this in a handful of lines — and understanding how it works is more useful than treating it as a black box.

Building Concurrent Ai Pipelines In Go · Part 11

Part 10 ran tasks concurrently inside one worker. Part 11 runs stages concurrently across the whole pipeline — scrape, clean, embed, and summarise each get their own worker pool, tuned to their specific bottleneck.

Building Concurrent Ai Pipelines In Go · Part 10

Arc 1 ran three AI tasks per article one after another. Part 10 runs them all at once — fan-out launches them concurrently, fan-in collects all three results, and per-article time drops from the sum to the slowest.