Rate limits and how to live within them
Every API you depend on will eventually tell you to slow down. Designing for that from the start saves a world of pain.
Almost every external service caps how many requests you can make in a window. Ignore those limits and your automation works fine in testing, then breaks the moment volume picks up. Rate limits aren't an edge case; they're a design constraint.
Plan for the cap, not the demo
A workflow that fires a hundred requests in a burst will sail through a small test and fail in production. Designing for rate limits means spreading work out, batching where the API allows, and treating a 'slow down' response as expected rather than exceptional.
Living within the limit
Queue the work, pace it to stay under the cap, and back off politely when you're told to. Cache what doesn't change so you're not asking the same question twice. Handled well, rate limits become a non-event instead of a recurring fire.
Rate limits don't break good systems. They break systems that pretended limits didn't exist.