Can we use Step function AWS over setTimeout for scheduling

Question

I wish to create API service where any client can pass his HTTP request and time in seconds after which the HTTP request should be executed. This is what I could think of

1. First create a lambda with nodeJS and use setTimeout to wait
2. Second create a step function to wait for x number of seconds would call my lambda to execute HTTP request

So, what are the pros and cons of each. setTimeout looks easy to implement and with no obvious flaws. What is the reason I should choose stepfunction?

Answer 1

These are some of the pointers that hit me when I saw your question:

1. Lambda can timeout. Whereas StepFunctions can wait for e.g. a year also.
2. Lambda will cost for the time it is waiting but StepFunction will not.
3. There is a limit on concurrent executions for lambda totalling to 1000 whereas a StepFunction can have maximum 1,000,000 open executions.

Refer this for more info:
https://docs.aws.amazon.com/step-functions/latest/dg/limits.html#service-limits-state-machine-executions
https://docs.aws.amazon.com/lambda/latest/dg/concurrent-executions.html#per-function-concurrency

Answer 2

I think you have a few things that you need to work through first:

1) Activities behave as an SQS queue, to which you basically say "hey gimme the next activity". They don't support any sort of "gimme the activity for this execution ARN I happen to know" or any way to get a "specific" activity.
1.a) You can get around this by having a poller that polls for your activities when they get into the scheduled state by the Step Function. You need to then store the activity information (like a unique key you setup) in a way that your true "handler" can get its data (and its subsequent taskToken).
1.b) Your true handler then gets its nod from your ECS scheduled thing, looks up its key in the database, does the work, and then uses the taskToken to inform.
1.c) There are variations of this that you could do in a crazy parallel/Wait kinda way, to avoid the ECS guy having to get at the poller database... you'd basically just do that part first and then with the taskToken in hand you would kickoff the ECS stuff.

Beyond the above - which I think would be your true blocker and much harder part - It sounds like you are requesting two new timeout settings: 

1) "ScheduledTimeoutSeconds" - how long it can wait in a scheduled state (before an Activity poller gets it) after which it would throw an error
2) "ActivityTimeoutSeconds" - how long it can take to actually handle, not including scheduling time, after which it would throw an error