Why Run Work Asynchronously?

Module 36's very first lesson stated plainly: "a callout can never run directly inside a trigger... moving a callout to run asynchronously sidesteps this constraint, covered in a later module." This is that module. Every synchronous limitation flagged since Module 25 — the 10-second callout window, the 100-query ceiling, the "can't callout from a trigger" rule — gets a genuine answer here.

// Synchronous: this line blocks until the callout finishes
HttpResponse response = new Http().send(request);

// Asynchronous: this schedules the work to run in a SEPARATE,
// later transaction, and the current transaction continues immediately
System.enqueueJob(new MyQueueableClass());

Running code asynchronously means it doesn't execute as part of the current transaction at all — it's queued to run in its own, separate transaction, at a time the platform decides (usually within seconds, but not guaranteed instantly). The current transaction doesn't wait for it; it continues immediately.

1. Callouts from a trigger. A trigger can never make a synchronous callout directly (Module 36) — but it can enqueue asynchronous work that makes the callout in its own separate transaction.
2. A fresh set of governor limits. Each asynchronous transaction gets its own complete budget — 100 queries, 150 DML statements, all reset — genuinely useful for processing more data than a single synchronous transaction could handle (Module 25's limits, given more room to work with).