A scraper was slow and the obvious fix was to throw more workers at it. That instinct is almost always wrong, and it is expensive.
I profiled it first. The real problem was that a heavy parsing step was running on the main loop and blocking everything else, including the network calls that were supposed to be happening in parallel. More workers would have just given me more things to block.
Moving that parsing off the main path gave a big throughput jump with the same number of machines and no new rate limit errors, because the work was finally overlapping the way I assumed it already was.
The lesson: slow almost always means something is blocking, not that you need more of everything. Profile for the bottleneck before you spend on scale. The fix is usually smaller and cheaper than the workaround.