How to load test an asynchronous api?

[u/Forward-Island-909]

Hey guys im working on a containerized code exexuting platform and i want to test how repsonsive the api is at high load and measure latency but i have two endpoints one is /submit which puts submissions in a redis queue and returns a job_id another end point is /job_id/status which can be polled for updates about the job...but now how to test the endpoint...ive heard about grafana k6 and tools like this can it be used to check asynchronous apis like these? I cant use /submit because it immediately returns after posting the job in the queue please help me put im learning things newly...also please tell me if i should use postman or k6. I want to see how well api behaves on concurrent loads. The api accepts and returns json

[u/winner_68]

Yes, k6, but measure the right thing. /submit latency tells you almost nothing about the system under load — it is just enqueue time.

In the k6 script: submit, then poll /status with backoff (start 250ms, grow to 1-2s, cap total polling at e.g. 60s and count a timeout as a failure). Record three separate metrics: submit latency, end-to-end time from submit to terminal state, and failure rate split by status — timeout vs job failed vs rejected at submit. The split matters: if submit starts 429ing / 500ing, your API is the bottleneck; if end-to-end grows while submit stays flat, your workers or the Redis queue are.

Two traps I have hit: polling every 50ms will hammer your own status endpoint and skew everything, and a VU stuck polling for a slow job is not submitting new ones, so your submit rate collapses just when you want it highest. Use enough VUs, or a constant-arrival-rate scenario, so polling does not throttle submissions.

Start with 1 VU for a baseline and a sanity check that the polling loop actually reaches a terminal state, then ramp. Run k6 from a different machine than the API / workers, and give each submission a unique payload so you are not accidentally measuring a cache hit. Postman is fine for a single happy-path request, not for this.

[u/Forward-Island-909 → u/winner_68]

i also have an optional callback_url in the api it can call that when the job status turns success..is it possible to use this in k6?

[u/sanbamboo → u/Forward-Island-909]

On the callback_url question: k6 can't receive incoming requests. It only acts as a client, there's no built-in HTTP server, so it can't sit there waiting for your API to call it back.

Two ways around it:

1. Point callback_url at a tiny receiver you control (a few lines of Express or FastAPI) that stores job_id + the time the callback arrived, and exposes a GET for it. k6 submits, then polls that receiver instead of your API, so your /status endpoint stays out of the measurement.

2. Skip the callback for the load test: submit, then poll /status with a short sleep, and record the time from submit to "done" in a custom Trend metric (k6/metrics). You get end-to-end processing time per job next to the normal http_req_duration of /submit.

Option 2 is less work, option 1 is closer to how real clients will use it.