Audience question about conflicting recommendations: keep the job as a thin wrapper calling a service object, or treat the job as a plain Ruby object and put logic directly in it. Paweł said it depends but he prefers doing basic idempotency/duplication checks in the job and then calling a service object or API, so repeated executions produce the same result. He also mentioned Sidekiq's delayed extension which can turn any class method into a background job, though it's removed in Sidekiq 7 and will likely live on as a separate gem.