If the underlying protocol is TCP (e.g. HTTP), then there will be no problem. Your downloader has a buffer in memory where it temporarily stores data that has been downloaded. It continually writes data from this buffer to disk. If the disk is slow, then the buffer will become full and the downloader won't ask the operating system to receive more data from the remote server. That means a similar buffer in the Windows TCP driver fills up. The TCP protocol guarantees that you won't have a problem if someone's buffers get full:
TCP uses an end-to-end flow control protocol to avoid having the
sender send data too fast for the TCP receiver to receive and process
it reliably. Having a mechanism for flow control is essential in an
environment where machines of diverse network speeds communicate. For
example, if a PC sends data to a smartphone that is slowly processing
received data, the smartphone must regulate the data flow so as not to
TCP uses a sliding window flow control protocol. In
each TCP segment, the receiver specifies in the receive window field
the amount of additionally received data (in bytes) that it is willing
to buffer for the connection. The sending host can send only up to
that amount of data before it must wait for an acknowledgment and
window update from the receiving host.
So, when the TCP driver's buffer is full, it won't acknowledge to the other computer that it's ready to receive more data.
If the underlying protocol is something more special / proprietary, then all bets are off - because this is a feature of TCP.