Taskiq + APScheduler: retries without the pain
At PDP Mobile, we built background processing on Taskiq + APScheduler so requests wouldn’t get lost, even if the CRM was “not in the mood today.” We set up delivery, retry logic, and delayed publishing.
At PDP Mobile, we built background processing with Taskiq + APScheduler so requests wouldn’t get lost, even if the CRM decided it was “not in the mood today” 😅
What we did:
— set up delivery guarantees for background jobs;
— added retry logic: if a request didn’t make it into the CRM, it is automatically recreated and sent for another attempt;
— for news items, we added delayed publishing with APScheduler: scheduled → published.
The most interesting challenge was server restarts. In real life, things don’t fail on schedule, and it matters that jobs don’t disappear into the void after a restart. We made them recover from the queue and continue processing.
Against the backdrop of the hype around reliable async pipelines and event-driven architectures, this is no longer a “nice to have” — it’s the baseline. When production lives its own life, mechanisms like this really save the day.