SolidQ 개발의 주된 동기는 Rescue 설정에서 누적된 복잡성이었습니다. 수년간 Rescue를 사용하면서 다양한 맞춤형 코드, 포크된 젬(gem)들이 쌓여 관리가 매우 어려워졌습니다. David Heinemeier Hansson은 이러한 복잡성을 해소하고자 데이터베이스 백엔드 기반의 새로운 시스템 구축을 제안했습니다. SolidQ는 Active Job이 제공하는 재시도, 오류 처리, 직렬화(serialization) 등의 기능을 최대한 활용하여 이러한 요구사항을 충족시키도록 설계되었습니다. 초기에는 애플리케이션과 동일한 데이터베이스를 공유하여 트랜잭션 무결성을 확보하려 했으나, 대규모 쓰기 부하 문제로 인해 결국 별도의 데이터베이스를 사용하는 방향으로 전환되었습니다. 또한, GoodJob과 같은 다른 데이터베이스 기반 큐 시스템이 PostgreSQL의 특정 기능을 활용하는 반면, 37 Signals는 MySQL을 사용하므로 SolidQ는 세 가지 공식 데이터베이스(PostgreSQL, MySQL, SQLite)를 모두 지원하도록 설계되었습니다.
마이그레이션 전략은 Hey 애플리케이션에서 시작되었습니다. 이는 Basecamp보다 사용자 수가 적고 중요도가 낮아 위험 부담이 적었기 때문입니다. 초기에는 사용자에게 영향을 미치지 않는 작업(예: 삭제된 데이터의 최종 삭제)부터 SolidQ로 전환했습니다. Active Job의 작업별 어댑터 정의 기능을 활용하여 Rescue와 SolidQ를 동시에 운영하며 점진적으로 작업을 이동시켰습니다. Kamal로의 마이그레이션과 겹치는 기간이 있었지만, 이는 배포를 단순화하는 데 도움이 되었습니다. Rosa Gutierrez는 장기 프로젝트에서 진행 상황을 기록하는 것의 중요성을 강조했습니다. SolidQ의 가장 큰 장점 중 하나는 데이터베이스에 작업 상태가 투명하게 저장되어 디버깅과 모니터링이 훨씬 쉬워졌다는 점입니다. Rescue의 Redis 리스트 구조에 비해 특정 작업 클래스별 필터링 등이 용이합니다.
작업 패턴에 있어서는, 37 Signals 팀은 작업을 가능한 한 작고 독립적으로 유지하는 것을 선호합니다. 이는 재시도 및 문제 해결을 용이하게 합니다. 작업 시스템을 오케스트레이터로 사용하는 것을 지양하며, 복잡한 종속성이 있는 작업 흐름은 코드 레벨에서 관리하는 것을 권장합니다. 장기 실행 작업(예: 데이터 내보내기)의 경우, 중단 시에도 상태를 유지하고 재개할 수 있도록 설계하는 것이 중요합니다. 또한, 매일 또는 주기적으로 실행되는 보고서 생성과 같은 반복 작업에는 자체 스케줄링 방식보다 크론(cron)과 유사한 반복 작업 기능을 사용하는 것을 선호합니다. 이는 작업 큐에 실패하더라도 다음 실행 시 자동으로 처리될 수 있어 안정성을 높이기 때문입니다. SolidQ는 이러한 반복 작업 기능을 내장하고 있습니다.
백그라운드 작업 테스트는 주로 모델에 비즈니스 로직을 배치하고, Active Job의 헬퍼를 사용하여 작업 인큐잉 및 재시도 동작을 확인하는 방식으로 이루어집니다. Rosa는 Steven Mar의 acidic_job 및 chaotic_job과 같은 젬을 통해 고급 테스트 시나리오를 시뮬레이션할 수 있다고 언급했습니다. 마지막으로, 마이그레이션이 완료된 후에는 Rescue 관련 코드와 같은 불필요한 코드를 적극적으로 삭제하여 코드베이스를 깔끔하게 유지하는 것이 중요하다고 강조했습니다. 이는 장기적인 유지보수성과 가독성을 높이는 데 기여합니다.