ActiveJob & Background Processing
Using ActiveJob on AWS Lambda is a reimagination of the problem for Rails. Instead of starting up long running process that polls for work, we instead use the event-driven architecture of AWS Lambda to our advantage using a gem named Lambdakiq which is mostly a drop-in replacement for Sidekiq.
It allows you to leverage AWS' managed infrastructure to the fullest extent. Gone are the days of managing pods and long polling processes. Instead AWS delivers messages directly to your Rails' job functions and scales it up and down as needed. Observability is built in using AWS CloudWatch Metrics, Dashboards, and Alarms. Key Features:
- Distinct web & jobs Lambda functions.
- AWS fully managed polling. Event-driven.
- Maximum 12 retries. Per job configurable.
- Mirror Sidekiq's retry backoff timing.
- Last retry is at 11 hours 30 minutes.
- Supports ActiveJob's wait/delay. Up to 15 minutes.
- Dead messages are stored for up to 14 days.
Learn more on GitHub: https://github.com/rails-lambda/lambdakiq
You may need lightweight background job processing similiar to how SuckerPunch gem works. The only way to do this for Lambda is to use the LambdaPunnch gem. LambdaPunch is a Lambda Extensions that works with the Lambda invoke model. This solution is required if you are using New Relic as described in our Logging & Observability guide.
Learn more on GitHub: https://github.com/rails-lambda/lambda_punch