Why not just await it?

The booking-confirmation email problem

A walker just confirmed a booking. Your route needs to send a confirmation email. The naive move: call the mailer with await right there in the request handler. But SMTP can take seconds, and the customer is sitting on a spinner waiting for a response that has nothing to do with whether their booking succeeded — the booking is already saved. Module 32 taught you not to block the event loop with sync calls; this is the same problem one level up: even an honestly-async, well-behaved wait doesn't belong on the critical path of a response the user is staring at.

FastAPI ships a built-in escape hatch for exactly this: BackgroundTasks. Add one to a route, and FastAPI runs it after the response is already sent back to the client — the customer sees "booking confirmed" instantly, and the email goes out a moment later, same process, same request lifecycle.