Job priorities and queues in Ruby on Rails

Introduction

Job priorities and queues help your app do many tasks in the background without slowing down the main work. You can decide which jobs are more important and run them first.

Sending emails after a user signs up without making them wait

Processing image uploads or resizing photos after upload

Running reports or data cleanup tasks overnight

Handling notifications or messages that don't need instant response

Managing tasks that might take a long time so the app stays fast

Syntax

Ruby on Rails

class MyJob < ApplicationJob
  queue_as :default

  def perform(*args)
    # Your job code here
  end
end

# To set priority, use different queues like :high, :default, :low
class HighPriorityJob < ApplicationJob
  queue_as :high

  def perform(*args)
    # Important job code
  end
end

Each job class sets which queue it belongs to with queue_as.

You can configure workers to process queues in order of priority.

Examples

This job sends a welcome email using the mailers queue.

Ruby on Rails

class EmailJob < ApplicationJob
  queue_as :mailers

  def perform(user_id)
    user = User.find(user_id)
    UserMailer.welcome_email(user).deliver_now
  end
end

This job runs in the low priority queue for less urgent tasks.

Ruby on Rails

class CleanupJob < ApplicationJob
  queue_as :low

  def perform
    # Clean old records
  end
end

This job runs in the high priority queue for urgent tasks.

Ruby on Rails

class CriticalJob < ApplicationJob
  queue_as :high

  def perform
    # Handle urgent task
  end
end

Sample Program

This example shows two jobs: one normal and one urgent. The urgent job runs first because it uses the high priority queue.

Ruby on Rails

# app/jobs/print_message_job.rb
class PrintMessageJob < ApplicationJob
  queue_as :default

  def perform(message)
    puts "Job says: #{message}"
  end
end

# app/jobs/urgent_job.rb
class UrgentJob < ApplicationJob
  queue_as :high

  def perform
    puts "Urgent job running!"
  end
end

# In Rails console or a script
# Enqueue jobs
PrintMessageJob.perform_later("Hello from default queue")
UrgentJob.perform_later

# Assuming Sidekiq or another adapter is running and configured to process queues
# with priority: high first, then default

# Output when jobs run:
# Urgent job running!
# Job says: Hello from default queue

Important Notes

Time complexity depends on the job's own code, but queueing is very fast (constant time).

Space complexity is minimal for queue metadata but depends on job data size.

Common mistake: Not configuring workers to respect queue priorities, so all jobs run in random order.

Use job priorities when some tasks must finish before others. Use separate queues to organize and control job flow.

Summary

Job priorities let you run important tasks before less important ones.

Queues group jobs by priority or type for better control.

Set queue_as in your job classes to assign priorities.

Practice

1. What is the main purpose of setting different job priorities in Rails Active Job?

easy

A. To run more important tasks before less important ones

B. To make jobs run slower

C. To delete jobs automatically

D. To run all jobs at the same time

Solution

1. Step 1: Understand job priorities concept

   Job priorities help decide which jobs run first based on importance.

2. Step 2: Identify the purpose in Rails

   Rails uses priorities to run important jobs before less important ones.

3. Final Answer:

   To run more important tasks before less important ones -> Option A

4. Quick Check:

   Job priorities = run important jobs first [OK]

Hint: Priorities mean important jobs run before others [OK]

Common Mistakes:

• Thinking priorities slow down jobs
• Assuming priorities delete jobs
• Believing all jobs run simultaneously

2. Which syntax correctly sets a queue name for a job class in Rails?

easy

A. queue_as :default

B. queue = :default

C. set_queue :default

D. queue_name = 'default'

Solution

1. Step 1: Recall Rails Active Job syntax

   Rails uses queue_as to set the queue name inside job classes.

2. Step 2: Match correct syntax

   queue_as :default is the correct way to assign the queue.

3. Final Answer:

   queue_as :default -> Option A

4. Quick Check:

   Use queue_as to set queue [OK]

Hint: Use queue_as :name inside job class [OK]

Common Mistakes:

• Using assignment (=) instead of queue_as
• Trying to set queue with unknown methods
• Using string instead of symbol incorrectly

3. Given this job class:

class EmailJob < ApplicationJob
  queue_as :mailers
  def perform(user_id)
    # send email
  end
end

Which queue will this job be added to when enqueued?

medium

A. jobs

B. default

C. emails

D. mailers

Solution

1. Step 1: Check the queue_as setting in the job class

   The job class sets queue_as :mailers, so it uses the 'mailers' queue.

2. Step 2: Understand enqueue behavior

   When enqueued, the job goes to the queue named 'mailers'.

3. Final Answer:

   mailers -> Option D

4. Quick Check:

   queue_as :mailers means queue is 'mailers' [OK]

Hint: queue_as sets the queue name exactly [OK]

Common Mistakes:

• Assuming default queue if queue_as is set
• Confusing queue name with job class name
• Picking similar sounding queue names

4. Identify the error in this job class:

class CleanupJob < ApplicationJob
  queue_as = :low_priority
  def perform
    # cleanup code
  end
end

medium

A. Job class must inherit from ActiveJob::Base

B. perform method must have an argument

C. queue_as should be called as a method, not assigned

D. queue_as must be a string, not a symbol

Solution

1. Step 1: Check how queue_as is set

   queue_as is a method call, not an assignment. Using '=' causes syntax error.

2. Step 2: Correct syntax for queue_as

   It should be queue_as :low_priority without '='.

3. Final Answer:

   queue_as should be called as a method, not assigned -> Option C

4. Quick Check:

   queue_as is a method call, not variable assignment [OK]

Hint: Use queue_as :name, not queue_as = :name [OK]

Common Mistakes:

• Using '=' with queue_as
• Forgetting to inherit from ApplicationJob
• Thinking perform must have arguments always

5. You want to run urgent jobs before normal jobs in Rails. You have two job classes:

class UrgentJob < ApplicationJob
  queue_as :urgent
  def perform
    # urgent task
  end
end

class NormalJob < ApplicationJob
  queue_as :normal
  def perform
    # normal task
  end
end

How can you ensure urgent jobs run before normal jobs when using Sidekiq?

hard

A. Rename UrgentJob to NormalJob

B. Configure Sidekiq to process the 'urgent' queue before the 'normal' queue

C. Set both jobs to the same queue

D. Run urgent jobs manually without Sidekiq

Solution

1. Step 1: Understand queue priority in Sidekiq

   Sidekiq processes queues in the order they are listed in its configuration.

2. Step 2: Set Sidekiq to prioritize 'urgent' queue

   Configure Sidekiq to check the 'urgent' queue before 'normal' to run urgent jobs first.

3. Final Answer:

   Configure Sidekiq to process the 'urgent' queue before the 'normal' queue -> Option B

4. Quick Check:

   Sidekiq queue order controls job priority [OK]

Hint: Set queue order in Sidekiq config for priority [OK]

Common Mistakes:

• Assuming queue_as alone controls priority
• Renaming job classes does not affect queue order
• Running urgent jobs manually is inefficient