Three limits, not one
A TCP sender is constrained by what the receiver says it can accept, what congestion control believes the network can sustain, and what the application actually supplies. An approximate model for a sustained flow is throughput ≤ min(rwnd, cwnd) / RTT, assuming the application keeps the socket fed and the path and endpoints impose no lower ceiling. Here rwnd is the advertised receive window and cwnd is the congestion window. They are different.
The receiving machine might have small receive buffers, slow application reads, or autotuning limits. In that case the sender sees a receiver-window ceiling even when the network is clean. TCP window scaling allows receive windows beyond the old 16-bit header limit, but support is negotiated during the SYN handshake. Enabling a larger socket buffer afterward does not repair a connection whose window scaling was never negotiated.
Or the receiver advertises 64 MB while the sender's congestion window is 4.5 MB because the connection suffered loss, is still ramping up, or follows a congestion controller that cannot maintain a large flight. Turning up receive buffers would not solve that case. A third possibility is an application that reads from object storage in tiny chunks or deliberately serializes network writes. The TCP stack cannot transmit bytes it has not been given.
I would check ss -ti or equivalent TCP diagnostics on both endpoints, packet traces when permitted, send and receive buffer measurements, retransmissions, RTT estimates, flow-control stalls and CPU or disk activity. Tools such as iperf3 can isolate path behavior from the actual application, but I would keep the test topology and security conditions representative.
The arithmetic changes the design
Suppose the team can raise the effective in-flight limit from 4.5 MB to 45 MB. The same idealized calculation gives around 2 Gbps, not 10 Gbps. To approach the full circuit rate at the stated RTT, we need roughly 225 MB in flight, subject to congestion control, receiver resources and all other endpoints sharing that path. More bandwidth alone helps little when this connection remains window-limited.
Now the interviewer offers 16 parallel transfers. Sixteen connections, each sustaining 200 Mbps, might deliver 3.2 Gbps in a favorable test. The calculation is straightforward. The guarantee is not. Parallel flows compete for buffers and link capacity. They may consume many more file descriptors, object-store requests and memory buffers, and they can be unfair to unrelated traffic. If the limitation is a shared route or receiver aggregate ceiling, adding connections just moves the bottleneck.
Parallel byte ranges can be reasonable for a bulk object copy, especially if the transfer tool can retry failed ranges and verify final checksums. They are a less comfortable default for a transactional API, where splitting work can alter ordering and error handling. The point is to choose concurrency because of a measured per-flow bottleneck, not because sixteen sounds faster than one.
What I would ship
First run a controlled path test with one sustained TCP stream, then several, recording sender and receiver TCP state. Compare the observed flight size to the 225 MB BDP. Check whether the limiting condition is receiver-advertised space, congestion behavior, application pacing, traffic shaping, or storage. Confirm that the measured RTT is representative in both directions and that the VPN or proxy does not introduce another limit.
If receive buffering is the issue, tune bounded buffer and autotuning settings with a rollback plan. If congestion control is limiting the flow, investigate retransmissions, ECN signals, pacing and the deployed algorithm instead of blindly enlarging queues. If the application starves the socket, change its I/O pipeline. If multiple connections are justified, cap concurrency and verify it does not degrade neighboring customers.
I would evaluate success using end-to-end transfer duration, retransmission behavior, memory use, fairness and delivered bytes, not merely the circuit's advertised capacity. A Principal-level answer should also consider whether transferring every object across an ocean is necessary. Regional placement or moving compute to data could eliminate a large recurring network bill.
The part worth remembering for the next network incident is that spare bandwidth tells you almost nothing about a single TCP flow until you know how much data it can keep outstanding. In the next question, the bottleneck changes: the flow has enough window space, but a small amount of packet loss keeps interrupting its progress.
