A load test is a planned increase in traffic, so it needs a boundary. Running an unlimited loop against a production podcast API can measure rate limiting more than application capacity and can affect other work sharing the credential.
Read the provider's terms and testing guidance. Use an approved environment and a request budget that fits your access.
Define the question first
Are you testing your own search proxy, a queue worker, or the whole upstream path? A mock upstream can help measure your application separately. A small controlled live check can then confirm the real connection without pretending to be a complete capacity study.
Choose concurrency, request rate, duration, endpoints, and stop conditions before starting. Use a realistic mix of queries and cache hits instead of one tiny response that stays hot in every layer.
Track latency distributions, error categories, cancellations, and upstream limits. An average response time alone can hide a slow tail that listeners notice.
Include recovery
After the traffic stops, check that queued work returns to normal and that the application has not left retries running. A system that appears fast during the test but keeps creating traffic afterward has not completed the exercise cleanly.
Avoid real listener writes unless a dedicated fixture design requires them. Keep exact cleanup ownership for any synthetic data.
Write the conclusion within the conditions you tested: a stated traffic level, request mix, duration, and environment. Do not turn a short successful run into a promise of unlimited scale.
A useful load test informs a concrete decision, such as a concurrency limit or cache change. It is not a reason to send the largest possible number of requests.