Delaying Jobs Beyond 15 Minutes in SQS
Language Mismatch Disclaimer: Please be aware that the language of this article may not match the language settings of your browser or device.
Do you want to read articles in English instead ?
AWS SQS only allows delays up to 15 minutes. That works for most cases, but not if you need sequences that stretch to days or weeks. I ran into this when trying to schedule emails for 24 hours, 3 days, and even 29 days. Locally, it worked fine. In production, it failed. The fix? Use Redis for long delays, while keeping SQS as the main queue.
Outline
- The problem with SQS delays
- Why 15 minutes isn’t enough
- Failed workarounds with retries
- Other AWS options (Lambda, scheduler)
- Redis as the solution
- Hybrid queue setup (SQS + Redis)
- What it taught me about senior dev problem-solving
The Problem With SQS Delays
AWS SQS has a hard limit: you can’t delay a job longer than 15 minutes. That’s fine for short retries but not if you need jobs scheduled across multiple days.
Why 15 Minutes Isn’t Enough
For my funnel, I needed to send follow-up emails after 24 hours, 3 days, and up to 29 days. Locally, I could delay jobs however long I wanted. But in production, the SQS limit hit me right away.
Failed Workarounds With Retries
At first, I thought I could requeue the job every 15 minutes. But retries come with limits too. And even if you set retries to unlimited, it wastes compute time and money. That approach was not sustainable.
Other AWS Options
Some suggested using Lambda with wait times or building a separate scheduling service. It works, but it adds complexity I didn’t want. For me, it felt like a non-issue that was getting over-engineered.
Redis as the Solution
Redis queues don’t have the 15-minute restriction. I switched my long-delay jobs (like email sequences) to Redis and kept SQS for everything else. This hybrid setup gave me both reliability and flexibility.
Hybrid Queue Setup
Now my main jobs run on SQS, while email funnels and nurture sequences run on Redis with custom delays. It’s a clean split: short real-time jobs on SQS, long-scheduled jobs on Redis.
What It Taught Me
This is where I really felt like a senior developer. It’s not just about writing code it’s about hitting unusual problems, weighing pros and cons, and picking the right trade-offs. Nobody tells you how to solve these edge cases. You figure it out by digging deep.
