Hi Alessandro, glad you liked the post. Thanks for the comment, that is a very interesting question.
You'll need to implement custom code. I can think of a few ideas, but need more investigation to come up with a proper architecture. Is it possible to detail a little more your use case?
start=current_timestamp + 30 seconds & end=current_timestamp + 90 seconds
current_timestamp == task_execution_timestamp
I said it's a naive idea because it ignores some important things:
Is it enough to run the task on a given second? Or do you need time resolution down to the millisecond, maybe microsecond?
That will have an impact over the implementation. Some programming languages will resolve time down to milliseconds, only.
If you're using AWS Lambda, beware that you can't control which machine is running your code. Could be multiple machines throughout a given period of time. It's actually most likely to be a different machine for every cold start.
This has important implications since there are issues with syncing clocks on distributed systems.
Depending on how much deviation you can accept in the "almost the exact time", this can be a problem.
How many tasks do you expect to schedule and how are they distributed over time?
Is it possible that you'll have 50,000 tasks to run on a given millisecond? If yes, the challenge will be setting an infra that can scale to that level of concurrent requests.
What happens if the triggering process of a task fails, or if the task executor fails entirely and a block of tasks is not executed at all.
Do you need a system in place to check for that and retry the task or can you afford having some tasks being lost?
Will it be too late if a few seconds have passed before retrying?
Is it a problem if, occasionally, the same task gets executed twice? If yes, a proper locking mechanism needs to be in place to ensure each task is processed once and only once.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.