@noisesmith you understood correctly, i am not sure i follow the second part though

danboykis is http-kit-call async?

yes

if yes, then the buffering on that channel does nothing to slow your requests

the go loop will grab more requests to send and send them as fast as they come in

the buffering does nothing to limit the number of requests in flight

if you use something that blocks (and switch from go-loop to thread with a loop) or parks, and start 1000 loops in either case, then you will know only 1000 requests maximum will be in flight

number of loops controls parallelism, capacity of channel does not

(and it loses control of parallelism if it calls something async internally)

that's why I sent another channel via slow-http-ch and then read from it in write-to-db

but those things don't control parallelism either

or do they?

how?

the size of slow-http-ch tells you how many clients can keep sending you data even though you are busy

that doesn't slow anything down, it just hides a speed difference (until it gets overloaded, or something downstream from it goes to fast and breaks something)

i thought the first go-loop would block once the channel is full, no?

right, but the thing reading the channel is not slowed down

is it the writer that you are trying to slow? maybe I'm confused

the problem is that the consumer of the slow-http-channel is calling something async

which means that your backpressure doesn't apply

ok, I see what you're saying

i'm not sure what the best way to handle this situation is

if you want N things in flight, then allow N loops to send one item at a time each

another option is to have some sort of backpressure derived from your backend - eg. if the server takes more than N ms. to serve a response then add a sleep of N*x to your loop before sending the next request (this may be a silly way to do it, there's probably a better design)

the problem is that the this service just falls down

it doesn't really degrade much

yeah, in that case you need to estimate and use artificial backpressure

another option is a throttled channel - only lets things through at a fixed rate and applies backpressure

there's various utilities in ztellman 's manifold library for this stuff

in fact using a throttled channel with a good limit on it, with your original design (and without the 1000 size buffer) might just do what you want

@noisesmith you're talking about this: https://github.com/brunoV/throttler ?

@danboykis https://github.com/ztellman/manifold/blob/master/README.md which includes throttle plus other useful async plumbing

thanks, I'll look into it!