Phase 3: How the Internet & APIs Actually Work · ~35 minutes · Python · asyncio

Why Blocking I/O Is a Problem

Three API calls at one second each took 3.01 seconds run one after another, and exactly 1.00 second run concurrently — the same three calls, the same total work, a real 3x difference that's measurable, not theoretical.

Hiring signal: Reaches for concurrency because of a specific measured I/O bottleneck, not by default or out of habit

What you will learn

Explain what 'blocking' actually means: the program does nothing while waiting
Distinguish synchronous from concurrent execution
Measure a real speedup from running independent I/O-bound calls concurrently
Explain why a correct synchronous version is often simpler, and why async isn't a default choice

Introduction

Type: Learn Languages: Python, asyncio Prerequisites: Lesson 02 (REST APIs and Reading Docs Cold) Time: ~35 minutes

Objective

Learning objectives

Explain what "blocking" actually means: the program does nothing while waiting
Distinguish synchronous from concurrent execution
Measure a real speedup from running independent I/O-bound calls concurrently
Explain why a correct synchronous version is often simpler, and why async isn't a default choice

What you're building

A script (concurrency_comparison.py) that:

Defines 3 simulated API calls using asyncio.sleep() with different, real delays of your choosing (not all identical — pick at least one shorter and one longer)
Times them run sequentially (plain calls, or time.sleep() versions) and prints the real elapsed time
Times the same 3 calls run concurrently with asyncio.gather() and prints the real elapsed time
Contains a comment stating the measured speedup and confirming it roughly matches this lesson's "close to the slowest single call" prediction
Separately, times a genuinely CPU-bound function (a real computation, no sleep) run 3 times sequentially vs. wrapped in asyncio.gather(), and states in a comment whether async helped — and why or why not

A script needs to: (1) download 5 independent files from 5 different URLs, and (2) then compute a checksum for each downloaded file. Which part, if any, would benefit from being converted to async?

This is exactly this lesson's I/O-bound-vs-CPU-bound distinction, applied to a two-part real task. Downloading 5 files involves real waiting on 5 independent network responses — precisely the situation this lesson measured a genuine 3x speedup for. Computing a checksum is pure computation once the file's bytes are already in hand — no waiting involved, matching this lesson's CPU-bound measurement that showed zero benefit (and slight overhead) from async. A well-designed version of this script would use async for the downloads specifically, and plain sequential code for the checksums.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.