Active Job framework in Ruby on Rails - Step-by-Step Execution

Concept Flow - Active Job framework

Define Job Class

↓

Enqueue Job

↓

Job Added to Queue

↓

Job Worker Picks Job

↓

Perform Job's perform Method

↓

Job Completes

↓

Optional Callbacks Triggered

Active Job lets you define background tasks, enqueue them, and workers run them asynchronously.

Execution Sample

Ruby on Rails

class MyJob < ApplicationJob
  queue_as :default

  def perform(name)
    puts "Hello, #{name}!"
  end
end

MyJob.perform_later('Alice')

Defines a job that prints a greeting and enqueues it to run later.

Execution Table

Step	Action	Details	Result
1	Define Job Class	MyJob inherits ApplicationJob with perform(name)	Job class ready
2	Call perform_later('Alice')	Enqueue job with argument 'Alice'	Job added to default queue
3	Worker picks job	Background worker fetches job from queue	Job instance created with name='Alice'
4	Call perform method	Run perform('Alice')	Outputs: Hello, Alice!
5	Job finishes	Job completes successfully	Job removed from queue
6	Optional callbacks	After perform callbacks run if defined	Callbacks executed if any

💡 Job completes and is removed from queue after perform method runs

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
name	nil	nil	'Alice'	'Alice'	'Alice'
job_instance	nil	nil	MyJob instance with name='Alice'	Same instance	Destroyed after completion
queue	empty	contains MyJob with 'Alice'	contains MyJob with 'Alice'	empty	empty

Key Moments - 3 Insights

Why doesn't perform_later run the job immediately?

perform_later only adds the job to the queue (see Step 2). The job runs later when a worker picks it (Step 3).

What happens if the job fails during perform?

If perform raises an error, the job may be retried or moved to a dead queue depending on configuration, not shown here.

How does the job get the argument 'Alice'?

The argument 'Alice' is passed when enqueuing (Step 2) and stored in the job instance for perform (Step 3).

Visual Quiz - 3 Questions

Look at the execution table, what is the output at Step 4?

A "Hello, Alice!"

B Job added to queue

C Job instance created

D Job removed from queue

💡 Hint

Check the 'Result' column at Step 4 in the execution_table

At which step does the job get removed from the queue?

A Step 2

B Step 5

C Step 3

D Step 6

💡 Hint

Look for when the queue becomes empty in variable_tracker and the 'Job removed from queue' note in execution_table

If you call perform_now instead of perform_later, what changes in the execution flow?

A Job is enqueued twice

B Job is added to queue but never performed

C Job runs immediately, skipping queue and worker steps

D Job runs only after callbacks

💡 Hint

Consider how perform_now differs from perform_later in Active Job behavior

Concept Snapshot

Active Job lets you run background tasks.
Define a job class with perform method.
Use perform_later to enqueue, perform_now to run immediately.
Jobs run asynchronously via workers.
Arguments pass through enqueue to perform.
Callbacks run after job completion.

Full Transcript

Active Job framework in Rails helps run tasks in the background. You define a job class inheriting ApplicationJob with a perform method. Calling perform_later enqueues the job with arguments. A background worker picks the job from the queue and runs perform with those arguments. After perform finishes, the job is removed from the queue and optional callbacks run. This lets your app do work later without blocking user requests. perform_now runs the job immediately without queueing. Variables like job arguments and queue state change step-by-step as the job moves from enqueue to execution to completion.