Bandwidth

Bandwidth is a capacity number. It tells you the largest amount of data a network path can deliver per unit of time under ideal conditions. A 1 Gbps link can, at best, push one billion bits every second, which is about 125 megabytes per second.

The water-pipe analogy holds up well. Bandwidth is the width of the pipe, not the speed of the water. A wider pipe moves more water at once, but a single drop still takes the same time to travel end to end. That travel time is latency, and it is a separate property.

People mix up bandwidth and speed constantly because internet providers advertise plans in Mbps. A 500 Mbps plan means the link can sustain up to 500 megabits per second of total throughput, not that any one request finishes 500 times faster than a slow connection.

Bandwidth is the theoretical maximum. Throughput is what you actually get after real-world losses: protocol overhead, packet loss, retransmissions, congestion, and shared usage. A 1 Gbps link rarely delivers a full 1 Gbps of useful application data. Achieving 940 Mbps of real throughput on a 1 Gbps Ethernet link is already considered excellent because TCP, IP, and Ethernet headers eat the rest.

Latency is the time for one packet to travel from source to destination, dominated by physical distance and the speed of light in fiber. A satellite link can have huge bandwidth and still feel sluggish because each round trip takes 500 ms or more.

The interaction matters. The bandwidth-delay product (bandwidth multiplied by round-trip latency) tells you how much data is in flight on the wire at any moment. On high-bandwidth, high-latency links this product is large, so TCP needs big window sizes to keep the pipe full. If the window is too small, you never use the bandwidth you paid for.

Bandwidth dominates for bulk transfers: streaming 4K video at 25 Mbps, downloading a 50 GB game, backing up a database to object storage, or replicating data between datacenters. Here you care about total volume, so a wider pipe directly cuts the transfer time.

Bandwidth almost never matters for small, chatty workloads. Loading a typical API response of a few kilobytes is bound by latency and the number of round trips, not bandwidth. Adding more bandwidth to a connection that sends tiny requests gives you nothing.

The practical trade-off in system design is provisioning. Over-provisioning bandwidth wastes money on links and egress fees you never saturate. Under-provisioning causes queuing and packet drops during traffic spikes, which TCP interprets as congestion and backs off, making everything slower. Cloud egress bandwidth is metered and billed, so AWS, GCP, and Azure all charge per gigabyte leaving their network, which makes bandwidth a direct cost line, not just a performance concern.

Netflix recommends roughly 15 to 25 Mbps of sustained bandwidth for a single 4K stream. If a household has a 50 Mbps connection, it can comfortably run two 4K streams at once, but a third will start to buffer because the pipe is full.

Netflix does not fight this with raw bandwidth alone. It uses adaptive bitrate streaming: the player measures available throughput in real time and switches to a lower-resolution, lower-bitrate version of the same video when bandwidth drops, so playback continues without stalling instead of freezing.

On the supply side, Netflix places its Open Connect caching appliances directly inside ISP networks. This shortens the path and means the high-bandwidth video traffic never has to cross congested internet backbone links, keeping both bandwidth and latency favorable for the viewer.