Got the same question, for the system design portion My answer was basically: SQL db: user table, jobs table cache in front of db multiple application servers load balancer in front a task runner service that ticks every 60 seconds to find jobs select * from jobs where startDateTime <= now () and completed = false and attempts = null The runner service will put jobs into a queue (kafka like) and then serverless fxns will consume jobs from the queue. Any failures would be put in a failed queue, and then we can do some special things like alert the user of a failed job, and then process the failures at a higher priority. aka, pop them into the front of the queue of jobs to complete. The big bottleneck would be the sql query to find the next tick of jobs. So I said, get rid of SQL entirely since such a simple system doesnt need any relational topography and just use a giant horizontally scalable key value store (redis, cassandra, even mongo) instead of the jobs table.