# Setting Up Background Jobs with Solid Queue in Property Web Builder: A Complete Guide

> Learn to set up background jobs with Solid Queue in Property Web Builder. Our guide simplifies installation and configuration for efficient job processing using Rails Active Job API.

- Repository: [Ed Tee/property_web_builder](https://github.com/etewiah/property_web_builder)
- Tags: how-to-guide
- Published: 2026-03-01

---

**Property Web Builder uses Solid Queue as its production-grade background-job engine, requiring only the gem installation, a database migration, and setting `config.active_job.queue_adapter = :solid_queue` in production to begin processing jobs via the standard Rails Active Job API.**

Property Web Builder leverages **Solid Queue** to handle intensive background processing like video generation and email delivery without external dependencies such as Redis. By integrating this database-backed job adapter (version ~> 1.0), the application gains reliable, production-ready concurrency using PostgreSQL for persistence and scheduling. This guide covers the complete setup process according to the `etewiah/property_web_builder` source code.

## Core Architecture and Installation

### Gem Dependency

Solid Queue is declared in the `Gemfile` at line 242, pinning the dependency to version 1.0:

```ruby

# Gemfile (line 242)

gem "solid_queue", "~> 1.0"

```

Running `bundle install` adds the Active Job adapter and necessary binaries to the project.

### Database Schema Setup

After installing the gem, the migration [`20251209180729_create_solid_queue_tables.rb`](https://github.com/etewiah/property_web_builder/blob/main/20251209180729_create_solid_queue_tables.rb) creates the full schema Solid Queue requires for operation. This includes tables for `solid_queue_jobs`, `solid_queue_processes`, `solid_queue_executions`, pauses, semaphores, and recurring tasks. These tables handle persistence, deduplication, scheduling, and concurrency control without external data stores.

## Configuration Files

### Production Environment Adapter

In [`config/environments/production.rb`](https://github.com/etewiah/property_web_builder/blob/main/config/environments/production.rb) at line 65, Rails is instructed to route all `ActiveJob` calls through Solid Queue:

```ruby

# config/environments/production.rb (line 65)

config.active_job.queue_adapter = :solid_queue

```

Development and test environments retain the default async adapter, ensuring background jobs only run via Solid Queue in production.

### Worker and Dispatcher Settings

The [`config/solid_queue.yml`](https://github.com/etewiah/property_web_builder/blob/main/config/solid_queue.yml) file defines runtime behavior for dispatchers and workers per environment. **Dispatchers** poll the database for ready jobs using configurable `polling_interval` and `batch_size` values. **Workers** fetch jobs from specific queues (configured via `queues: "*" ` or named arrays) and execute them in thread pools sized by the `threads` parameter.

The production configuration defines dedicated queues for high-priority email, notifications, default work, and low-priority batch jobs, each with tuned thread counts and polling intervals. Solid Queue monitors worker health via the `solid_queue_processes` table; heartbeats enable automatic recovery of stalled jobs.

## Creating and Enqueuing Jobs

### Defining Job Classes

Jobs subclass `ApplicationJob` and specify their target queue using `queue_as`. In [`app/jobs/generate_listing_video_job.rb`](https://github.com/etewiah/property_web_builder/blob/main/app/jobs/generate_listing_video_job.rb), the implementation looks like this:

```ruby

# app/jobs/generate_listing_video_job.rb

class GenerateListingVideoJob < ApplicationJob
  queue_as :default   # optional; matches a worker's `queues` entry

  def perform(video_id:, website_id:)
    # Heavy-weight video generation logic…

  end
end

```

### Enqueueing with perform_later

Any service object or controller can enqueue work using `perform_later`. The call is persisted to `solid_queue_jobs` and picked up by a dispatcher:

```ruby

# Anywhere in the application (e.g., a service object)

GenerateListingVideoJob.perform_later(
  video_id:   video.id,
  website_id: website.id
)

```

For high-priority mailers, assign a specific queue that matches a dedicated worker in [`solid_queue.yml`](https://github.com/etewiah/property_web_builder/blob/main/solid_queue.yml):

```ruby
class MailerJob < ApplicationJob
  queue_as :mailers   # matches the high-priority mailers worker

  def perform(user_id)
    # send email…

  end
end

MailerJob.perform_later(user.id)

```

### Scheduling Future Jobs

Solid Queue supports delayed execution via the Active Job `set` API, creating a row in `solid_queue_scheduled_executions`:

```ruby
RefreshPropertiesViewJob.set(wait: 5.minutes).perform_later(website_id: 42)

```

The dispatcher monitors `scheduled_at` timestamps and moves jobs to the ready queue when the wait period expires.

## Summary

- **Solid Queue** provides database-backed background processing in Property Web Builder via the standard Rails Active Job interface.
- Installation requires the gem in `Gemfile` (line 242), running the migration [`20251209180729_create_solid_queue_tables.rb`](https://github.com/etewiah/property_web_builder/blob/main/20251209180729_create_solid_queue_tables.rb), and setting `config.active_job.queue_adapter = :solid_queue` in [`config/environments/production.rb`](https://github.com/etewiah/property_web_builder/blob/main/config/environments/production.rb) (line 65).
- Runtime behavior is controlled through [`config/solid_queue.yml`](https://github.com/etewiah/property_web_builder/blob/main/config/solid_queue.yml), which defines dispatcher polling intervals, batch sizes, and worker thread pools for specific queues.
- Jobs are defined by subclassing `ApplicationJob` and using `queue_as`, then enqueued with `perform_later` or scheduled with `set(wait: ...)`.

## Frequently Asked Questions

### What database tables does Solid Queue create in Property Web Builder?

According to the migration [`20251209180729_create_solid_queue_tables.rb`](https://github.com/etewiah/property_web_builder/blob/main/20251209180729_create_solid_queue_tables.rb), Solid Queue creates tables including `solid_queue_jobs` (for job records), `solid_queue_processes` (for worker heartbeats), `solid_queue_executions` (for tracking attempts), and `solid_queue_scheduled_executions` (for delayed jobs). These tables manage persistence, concurrency, and recovery without requiring Redis.

### How do I configure separate worker pools for different job priorities?

Edit [`config/solid_queue.yml`](https://github.com/etewiah/property_web_builder/blob/main/config/solid_queue.yml) to define multiple worker blocks, each specifying a `queues` array (e.g., `[mailers]` or `[default]`) and a `threads` count. The production configuration separates high-priority mailers from low-priority batch work by assigning distinct workers to specific queues with appropriate thread pool sizes.

### Can I schedule a job to run at a specific time instead of immediately?

Yes. Use the standard Active Job API: `YourJob.set(wait: 10.minutes).perform_later(args)`. Solid Queue stores this in `solid_queue_scheduled_executions` and automatically promotes it to the ready queue when the `scheduled_at` timestamp is reached, as implemented in the Property Web Builder source.

### Why does Property Web Builder use Solid Queue only in production?

The adapter is explicitly set to `:solid_queue` only in [`config/environments/production.rb`](https://github.com/etewiah/property_web_builder/blob/main/config/environments/production.rb) (line 65). Development and test environments use the default async adapter to avoid database overhead and simplify debugging, ensuring background jobs run instantly during local development without the Solid Queue polling infrastructure.