Case study 05 — Anlytic
Running one large request in parallel
Configurable actions against many rows at once, with results written back where they came from.
Bounded
work in flight
Spread
across lanes
Isolated
execution
The problem
Users attach an integration to rows of their own data, configure it against their own columns, and get structured results back. A single request can carry several actions across a great many rows, which is where a naive design falls over.
How it fits together
What I did
Check before starting
The whole request is validated up front, so a bad configuration fails immediately rather than halfway through a long run.
Bound the concurrency
Work is dispatched in parallel but with a ceiling, so one large request cannot exhaust the system it is running on.
Spread the load
How work is keyed decides which lane it lands in. Chosen carelessly, an entire import queues behind one consumer while everything else sits idle.
The hard part
The keying decision. It is one line of code, and most of the throughput depends on it. Key by something natural and every row of one big import lands in the same lane, which is the bottleneck the parallelism was meant to avoid.
Stack
Written at the level the reasoning survives. Internal specifics are left out on purpose.