Simple Serverless Scheduler – DEV Community

After I was engaged on the license key administration answer for my utility CloudPouch I needed to face the deferred cancelation of paid subscriptions drawback.

When a consumer cancels his/her subscription for some motive, the license key should work till the tip of the present billing interval. Because the use case shouldn’t be sophisticated, I made a decision to unravel it so simple as attainable, utilizing the out there Serverless companies, following the rules of architecture-controlled structure.

Serverless scheduler

The subject of the serverless scheduler has been showing pretty commonly for years. For my part, this can be a repetitive drawback that AWS ought to present us with a managed answer. Discussions within the AWS Neighborhood Builders Slack channel haven’t introduced any results, and we nonetheless have to implement it by ourselves.

Luckily, AWS gives a number of primitives that you should use whereas constructing your individual scheduler. The preferred choices are:

  • DynamoDB TTL
  • CRON in EventBridge (was once in CloudWatch)
  • StepFunctions.

Collection of an answer for a enterprise drawback

The options talked about above differ considerably from one another.

Foremost, they provide totally different accuracy of operation (delay) by way of the interval between the designated and the precise time of calling. For instance, for Dynamodb TTL it can be up to 48 hours. Whereas utilizing CRON in EventBridge, we are able to invoke a Lambda operate each minute. Enormous distinction, proper?

That is a very powerful, practical attribute as a result of it instantly impacts the implementation of enterprise necessities. In quite a few situations, it’s troublesome to think about enterprise stakeholders accepting a two-day hold-up in a response to a consumer motion.

Different traits that we are able to describe these options are additionally vital. For a lot of, the utmost variety of scheduled actions will likely be as vital as accuracy. One other characteristic would be the most time to postpone the motion sooner or later. And naturally, whether or not the motion is cyclical or one-off.

Going additional, one can not neglect about the price of working, and the extent of complexity of the answer, instantly affecting the time of implementation.

Taking all these traits under consideration, it shortly seems that there are lots of choices and the ultimate answer is dependent upon the necessities.

Enterprise case

The CloudPouch software is a desktop utility for evaluation and optimization of the AWS cloud prices. It’s out there within the subscription mannequin, for a small month-to-month or annual price. Every buyer has the chance to cancel their subscription at any time. In such case, the license key should be legitimate till the tip of the present billing interval, for which the price has already been charged. Check out t1 time level introduced within the diagram.

The mechanism should work analogously for annual subscriptions.

Collection of the answer

Given the enterprise necessities and the traits of AWS companies, I made a decision to decide on an answer that would be the best to implement and use. It was a basic architectural trade-off as a result of the simplicity of implementation was obtained at the price of accuracy.

Selecting the Dynamodb TTL (Time to Reside) mechanism turned out to be the very best on this case as a result of:

  • Accuracy (delay) shouldn’t be a very powerful for me, within the worst-case situation my buyer will obtain 2 further days of subscription free of charge 😉
  • I don’t want cyclical calls – a selected license will be canceled solely as soon as
  • It is easy to implement – the DynamoDB desk itself and its stream are all you want
  • It’s consistent with the Occasion-Pushed Structure, AWS will routinely set off scheduled motion sooner or later – push as an alternative of pull strategy.
  • Permits you to simply test which licenses are to be canceled sooner or later – simply view the weather within the DynamoDB desk
  • is the most affordable, though, with my scale, each answer can be free 😉

Implementation of the answer

The answer could be very easy and consists of a Lambda operate and a DynamoDB desk with a stream.

Solution architecture

In response to the cancelation of a subscription carried out by the consumer, an occasion is shipped to the eventBus within the EventBridge. Due to the outlined guidelines, this occasion is redirected to the Lambda operate Scheduler (in the true answer, different parts devour this occasion as nicely). The Lambda operate ‘Scheduler’ saves within the Scheduling desk details about the license to be canceled. This factor (“file”) has a fundamental construction, it consists of knowledge that permits you to determine the license within the desk Paidlicenses and the time when that is going to occur.

The cancelation date is saved within the Unix time format beneath the attribute specified within the configuration of the DynamoDB desk. I referred to as this attribute ttl, it was outlined in CloudFormation definition of the desk, at line 10:

  Sort: AWS::DynamoDB::Desk
      - AttributeName: PK
        AttributeType: S
      - AttributeName: PK
        KeyType: HASH
    TimeToLiveSpecification: # ttl definition
        AttributeName: ttl
        Enabled: true
    BillingMode: PAY_PER_REQUEST
    TableName: Scheduling
      StreamViewType: OLD_IMAGE
Enter fullscreen mode

Exit fullscreen mode

When utilizing Node.js (JavaScript), take note of the ttl calculation. It should be supplied in seconds and never milliseconds. Therefore, the division by 1000:

Math.flooring(new Date(cancelationDateAsString).getTime() / 1000)
Enter fullscreen mode

Exit fullscreen mode

How does it work

The AWS DynamoDB service continuously displays our desk and when the ttl worth is older than the present time, it can delete the factor.

For the entire answer to make sense, we should react to the deletion occasions of parts. We do it with a stream, which triggers the DeactivatePaidLicense operate. The payload despatched to this operate accommodates all the information of the factor that was beforehand saved within the ‘Scheduling’ desk, due to which the operate is aware of which license to cancel by making the suitable replace within the desk PaidLicenses.

The connection between the stream and the Lambda operate is outlined within the serverless.yml:

    handler: src/deactivatePaidLicense/operate.handler
    description: Deactivate license upon Paddle occasion
      - stream:
          kind: dynamodb
          arn: !GetAtt SchedulingTable.StreamArn
          maximumRetryAttempts: 1
          batchSize: 1
            - eventName: [REMOVE]
Enter fullscreen mode

Exit fullscreen mode

I used a filter right here, due to which the operate will likely be referred to as solely on account of eradicating the factor from the desk. On this manner, we switch logic from our code to the configuration of the AWS infrastructure, which is after all the finest follow 😃


The Scheduling desk is an impartial desk that solely shops scheduled cancelations. I did not use the single-table design strategy right here, so I haven’t got to fret about removals of different entity varieties.

Resolution in motion

My cursory assessments have proven that the DynamoDB within the us-east-1 area deletes the weather with a delay of 10 to 12 minutes after a delegated time within the ttl attribute. It’s a lot sooner than over talked about 48 hours restrict, however nonetheless is probably not acceptable for a lot of options. As well as, I need to spotlight that whereas these are typical delay occasions, we have now no assure that they may all the time be like that.

My observations coincide with tests carried out by Yan Cui a while in the past.

In abstract, I need to conclude that minimal time spent on implementation delivered a completely practical answer that meets my enterprise wants & is straightforward to function. And that is what I used to be aiming for 😃

Add a Comment

Your email address will not be published. Required fields are marked *