Active Job Adapter (Sidekiq)
Fast recall
Quick revision
Core answer
config.active_job.queue_adapter = :sidekiq, perform_later serializes an Active Job payload and Sidekiq runs it through its adapter wrapper. Active Job supports typed arguments and GlobalID for persisted records, while native Sidekiq expects JSON-compatible values. The abstraction enables common Rails helpers and easier backend changes, but retry semantics, performance, priorities, and advanced features still depend on the chosen adapter.Whether you know Active Job abstracts job backends and Sidekiq is one adapter (config.active_job.queue_adapter = :sidekiq).
Passing non-serializable args (symbols/objects become strings via JSON) — pass IDs instead.
Active Job abstracts job backends; Sidekiq is one adapter (config.active_job.queue_adapter = :sidekiq). Define job < ApplicationJob; perform_later; Sidekiq runs it.
Interview-ready guide
Interview answer
Active Job is the Rails framework for defining background jobs with a common interface. A job inherits from ApplicationJob, declares a queue with queue_as, implements perform, and is enqueued with perform_later. The configured adapter decides where that serialized work goes.
When the adapter is :sidekiq, Rails serializes the Active Job payload and Sidekiq stores and executes a wrapper that hands it back to Active Job. The Rails web process still needs a running Sidekiq backend and worker; selecting an adapter does not execute jobs by itself.
For example, WelcomeEmailJob.perform_later(user) can serialize the persisted user through GlobalID. At execution Active Job locates that record before calling perform. If the user was deleted in the meantime, deserialization can raise before the first line of the job body, so that failure needs an explicit policy.
Native Sidekiq jobs use perform_async and JSON-compatible arguments directly. They expose Sidekiq's API with less wrapper overhead. Active Job gives Rails-standard callbacks, testing helpers, mailer integration, and a more portable surface, but not every backend feature or semantic maps identically.
Retry behaviour needs particular care because Active Job's retry_on and Sidekiq's own retry system can form layers. I choose one documented policy for each exception class, verify queue names and execution in the deployed adapter, and treat changing backends as a tested migration rather than a configuration-only promise.
Active Job Adapter (Sidekiq)
Direct Answer
Active Job is Rails' common API for declaring and enqueueing jobs; a queue adapter chooses the backend that stores and executes them. With config.active_job.queue_adapter = :sidekiq, perform_later serializes an Active Job payload and Sidekiq runs it through its adapter wrapper. Active Job supports typed arguments and GlobalID for persisted records, while native Sidekiq expects JSON-compatible values. The abstraction enables common Rails helpers and easier backend changes, but retry semantics, performance, priorities, and advanced features still depend on the chosen adapter.
Deep Dive & Architecture
Active Job owns the application-facing envelope: job class, queue, arguments, locale, execution metadata, callbacks, and error declarations. The adapter translates that envelope into the backend's payload and scheduling API. Sidekiq later invokes an adapter wrapper, which reconstructs the Active Job and calls its execution pipeline.
GlobalID serializes a locator for a persisted model rather than the object's full current state. This is convenient and allows the worker to load fresh data, but the locator may no longer resolve. A raw ID handled inside perform gives the job control over not-found behaviour; a GlobalID failure can occur during argument deserialization.
Portability exists at the common API layer. Throughput, transaction integration, priority mapping, scheduling precision, retry storage, uniqueness, batches, and administrative tools remain backend-specific. Application code coupled to those features needs an explicit adapter boundary or accepts that switching requires redesign.
Tests should prove both levels. Active Job helpers can assert enqueueing and perform the job in a controlled adapter. At least one deployed-environment check must prove the Sidekiq process consumes the configured queue and that retry, serialization, and database visibility behave as expected.
Code Example
# config/application.rb
class Application < Rails::Application
config.active_job.queue_adapter = :sidekiq
end
class WelcomeEmailJob < ApplicationJob
queue_as :mailers
discard_on ActiveJob::DeserializationError
def perform(user)
UserMailer.welcome(user).deliver_now
end
end
WelcomeEmailJob.perform_later(user) # persisted model uses GlobalID
Common Mistakes & Pitfalls
Passing non-serializable args (symbols/objects become strings via JSON) — pass IDs instead.
Check your understanding
Answer these without looking back at the article.
- What happens between `perform_later` and a Sidekiq worker calling `perform`?
- How does passing a GlobalID differ from passing a raw record ID?
- Why can `retry_on` and Sidekiq retries create two retry layers?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.