When Rails work leaves the request-response cycle via background jobs, after_commit callbacks, or async mailers, it crosses an execution boundary that fundamentally changes how the code behaves. Five key dimensions shift: time (state may change before the job runs), state (jobs re-enter from persisted data, not in-memory context), database visibility (jobs enqueued inside transactions may not see uncommitted records), failure model (retries make idempotency a correctness requirement, not a polish), and discoverability (lifecycle hooks hide side effects from the initiating code). Practical guidance includes revalidating state inside jobs, using after_commit deliberately, designing jobs as resumable idempotent operations, preferring explicit orchestration for multi-step business flows, and treating every boundary crossing as a design decision rather than a convenience.
Table of contents
The model changes #Time changes #State changes #Transactions change visibility #Failure changes #Lifecycle hooks change discoverability #Upgrades expose the boundary #Make the boundary explicit #The point #Sort: