Two-part talk by Paweł Dąbrowski at wroclove.rb 2022. Part one ('on the surface') covers good practices: naming jobs meaningfully, keeping parameters simple (pass references not values), avoiding enqueueing jobs inside DB transactions, keeping job logic small so retries are cheap, using a Redis connection pool for both app and Sidekiq, preferring Ruby's prepend/modules over inheritance for shared job concerns, handling retries so errors are only logged to monitoring once retries are exhausted (via an error-wrapper pattern and the sidekiq_retries_exhausted hook), and logging only meaningful data (including a middleware that adds job arguments to logs). Part two ('under the hood') explains how Sidekiq uses Redis: push flow (validate, assign defaults, client middleware, JSON verification, ZADD for scheduled jobs or SADD+LPUSH for immediate jobs) and pull flow (poller uses ZRANGEBYSCORE to move due jobs, manager uses BRPOP on queues, decodes payload, runs server middleware, instantiates the class and calls perform). Mentions the Sidekiq dashboard is a small Rack app with ERB views, and that Pro/Enterprise are paid gems distributed via a private RubyGems server.