5 exercises — practice Mbps, Gbps, latency in milliseconds, and the critical bandwidth vs. latency distinction. Learn to explain network performance numbers accurately.
0 / 5 completed
Key network bandwidth vocabulary and conversions
"Bandwidth (Mbps/Gbps) = pipe width — how much data per second. Latency (ms) = pipe length — how long one request takes."
"1Gbps = 125MB/s (divide by 8 to convert bits to bytes)."
"Latency accumulates: 10 sequential calls at 2ms each = minimum 20ms added to total request time."
"CDN reduces latency by reducing distance — not by increasing bandwidth."
"Is X ms fast?" — depends on use case: interactive API needs p99 < 50-100ms; batch jobs are far more tolerant."
1 / 5
A team says "our API has 100Mbps bandwidth." A user complains about slow responses. Why might bandwidth not be the problem?
Option B correctly distinguishes bandwidth from latency. These are the two most confused networking concepts: (1) Bandwidth = the pipe width — how much data can flow per second (100Mbps = 12.5MB/s), (2) Latency = the pipe length — how long a single bit takes to travel from source to destination. A "slow API" almost always means high latency, not low bandwidth. You can have a 10Gbps connection with 300ms latency that feels very slow for interactive applications. Conversely, a 10Mbps connection with 5ms latency feels fast for most APIs. Option A is wrong — 100Mbps can absolutely be a bottleneck for high-volume data transfer. Option C blames the user without evidence. Option D conflates two distinct metrics.
2 / 5
Your office internet is "1Gbps." A colleague wants to download a 10GB backup file. About how long should this take in theory?
Option B is correct. The critical unit conversion: 1Gbps = 1 Gigabit per second = 125 Megabytes per second (divide by 8, since 1 byte = 8 bits). So 10GB / 125MB/s = 80 seconds. Option B also adds the important caveat: real-world speed is lower due to TCP overhead, the server's upload bandwidth, network congestion, and disk I/O on both ends. This is why the common rule is "real-world throughput is roughly 60-80% of advertised bandwidth." Option A says 10 seconds — this confuses Gbps with GB/s (1Gbps ≠ 1GB/s). Option D makes the same error. The unit trap: always convert bits to bytes (÷ 8) when calculating file transfer times. 1Gbps internet is ~125MB/s actual throughput at best.
3 / 5
A system design document says "inter-service latency: 2ms." What does this mean practically for an API that makes 10 downstream calls?
Option B demonstrates understanding of latency accumulation in distributed systems. Key concepts: (1) Sequential calls add up: 10 calls × 2ms = 20ms minimum just from network hops, before any processing, (2) p99 variance: the first 9 calls might be 2ms, but the 10th (already at p99 of all your services) could be 20ms — tail latency compounds across calls, (3) Parallelisation: if any downstream calls are independent, making them in parallel reduces total latency to max(individual call times) rather than sum. Jeff Dean's "Numbers Every Engineer Should Know" makes exactly this point: at 2ms each, 10 sequential RPCs cost 20ms — this is why microservice call graphs must be carefully designed. Option A and C dismiss a real concern. Option D is wrong — calls add up.
4 / 5
Which sentence correctly uses networking vocabulary in a technical explanation?
Option B is the technically correct CDN explanation. It: (1) explains the mechanism ("geographically closer nodes"), (2) quantifies the improvement with real-world numbers (~180ms transatlantic → ~20ms local PoP), (3) explains how bandwidth improves separately ("dedicated peering at PoPs"), (4) does not conflate latency and bandwidth — these are explained as distinct improvements. Option A says CDN reduces latency "because it increases bandwidth" — this is a causal error: CDN reduces latency by reducing distance, not by increasing bandwidth. Option C says CDN "caches bandwidth" — bandwidth is not something you cache; you cache content. Option D uses "so performance is better" — this conflates two metrics without explaining how they affect the user experience differently.
5 / 5
An engineer says "our service has 50ms p99 latency." A product manager asks "is that fast?" Which contextual answer is most accurate?
Option B gives the correct context-dependent answer to "is X ms fast?" Key points: (1) use case dependency — latency requirements vary enormously by application type, (2) Google research: 100ms is the threshold where users notice delay; 50ms p99 gives comfortable headroom for interactive applications, but 50ms is just one component of total page load time, (3) p99 interpretation: 50ms p99 means 99% of requests are faster than 50ms — but it also means 1% are ≥50ms, and with load spikes or tail variance, some users see much higher, (4) for sub-100ms page load targets, the API's 50ms p99 needs to be added to frontend rendering time. Option A makes a universal claim without context. Option C sets an unrealistic universal target (single-digit ms is only achievable for very specific, highly optimised operations). Option D invents an "industry standard" that doesn't exist.