{"id":342,"date":"2021-02-02T14:42:00","date_gmt":"2021-02-02T14:42:00","guid":{"rendered":"https:\/\/www.simplybusiness.co.uk\/go-routines-aws-lambda\/"},"modified":"2025-05-22T13:19:12","modified_gmt":"2025-05-22T13:19:12","slug":"go-routines-aws-lambda","status":"publish","type":"post","link":"https:\/\/www.simplybusiness.co.uk\/about-us\/tech\/2021\/02\/go-routines-aws-lambda","title":{"rendered":"Go routines for stateless AWS Lambda functions"},"content":{"rendered":"\n

I love serverless<\/a>. I’ve written about it before in my previous post on how to implement a third-party logs ingestion workflow<\/a>, but I now want to tackle the question: ‘Is it possible to scale stateless serverless functions on the runtime as opposed to leveraging function concurrency?’<\/em><\/p>\n\n\n\n

In short, my answer is yes.<\/p>\n\n\n\n

Stateless vs stateful applications<\/h2>\n\n\n\n

In the context of AWS Lambda<\/a>, serverless makes it easier to scale up applications in multiple parallel executions. However, this also implies that stateful applications need to rely on some form of external storage to share memory. This is the only asynchronous way by which function invocations can \u2018communicate\u2019 with each other about their evolving status.<\/p>\n\n\n\n

This adds to the complexity. It is somewhat harder to design a system that does not store its shared status on any form of local resource, be it volatile memory or the filesystem. But is it always necessary to avoid all forms of local sharing in the serverless runtime environment?<\/p>\n\n\n\n

I believe the answer is no. Purists may shudder at this but I will try to make my case.<\/p>\n\n\n\n

It really depends on whether the application you’re writing is stateful as opposed to stateless.<\/p>\n\n\n\n

If you’re writing code that runs periodically and perpetually, with a need to communicate its evolving status, (and this is what I mean by stateful) then pushing the runtime for more parallelism is not an idea that will significantly simplify your application design. You’ll still need to have external storage in which to track the status, as the runtime existence is ephemeral and bound in time.<\/p>\n\n\n\n

If instead your application is stateless, then much can be gained by leveraging parallel executions on the runtime itself.<\/p>\n\n\n\n

Let\u2019s consider an example. You want to write a scavenger function that periodically checks whether entries on a DynamoDB table are old enough to be deleted, so that the table is kept minimal and scan operations consume less read capacity. In short, you want to save on your DynamoDB bill.<\/p>\n\n\n\n

This is an example of a stateless application. The single application run – or Lambda function invocation – does not need to know anything about previous runs.<\/p>\n\n\n\n

By increasing the parallelism on the Lambda runtime environment, we get more speed, and possibly some savings on the Lambda bill.<\/p>\n\n\n\n

If we were instead invoking the Lambda function multiple times in parallel, we would possibly be getting multiple cold starts, together with having to share an application status. That would be necessary to avoid having the same segments in our DynamoDB table being read by different Lambda invocations, thus giving up the benefits of parallel execution. In short, we’d be introducing a status for a conceptually stateless invocation. It doesn\u2019t sound right.<\/p>\n\n\n\n

Language considerations<\/h2>\n\n\n\n

Now this is where I get excited. Increasing the parallelism of code is something that can be done in any language supporting multithreading.<\/p>\n\n\n\n

Golang<\/a> has been my language of choice, because I think the Go pattern of sharing memory by communicating fits very well with stateless AWS Lambda functions.<\/p>\n\n\n\n

Go support for cheap routines and channels is outstanding. Together with the support for context cancellation provided by the package context<\/a>, it makes a great candidate language for programming a parallel function for the Lambda runtime.<\/p>\n\n\n\n

\"sb-tech-site-technology\"<\/a><\/figure>\n\n\n\n

The parallel implementation<\/h2>\n\n\n\n

Let’s revisit the example of the scavenger function. How do we translate our thoughts into code?<\/p>\n\n\n\n

Here’s the code sample for our implementation, and some guidelines for interpreting the code snippet:<\/p>\n\n\n\n