Ask HN: Options for handling state at the edge?

With Cloudflare workers able to be called single digit ms away from customers on much of the planet now, I wonder how I can keep state as close to the workers / lambdas as possible.

What are the options we have for handling state as the edge? What do you use in your business or service?

I recently had an opportunity to build an application on top of Lambda@Edge (AWS's equivalent of Cloudflare workers). The prevailing wisdom there was to make use of regional services, like S3 and DynamoDB, from the edge. That, of course, makes my edge application depend on calls to a larger, further away point of presence.

While it's possible to distribute state to many AWS regions and select the closest one, I ended up going a different route: packaging state alongside the application. Most of the application's state was read-only, so I ended up packaging the application state up as JSON alongside the deployment bundle. At startup, it'd then statically read the JSON into memory - this performance penalty only happens at startup, and as long as the Lambda functions are being called often (in our case they are), requests are as fast as a memory read.

When the state does need to get updated, I just redeploy the application with the new state.

That strategy obviously won't work if you need "fast" turnaround on your state being in sync at all points of presence, or if users can update that state as part of your application's workflow.

I have used card database files before with success. https://cr.yp.to/cdb.html

Have your process regularly update the CDB file from a blob store like S3. Any deltas can be pulled from S3 or you can use a message bus if the changes are small. Every so often pull the latest CDB down and start aggregating deltas again.

CDB performs great and can scale to multiple GBs.

I think this is a really clear winner for something like Litestream, where you can have state far away but sync it locally with periodic syncs if you can live with 'small wait on startup' and 'periodic state updates'.

We do something similar in Climatiq on Fastly's Compute@Edge. When building the application we load in a big chunk of read-only data in-memory, and serialize that memory to a file. When we spin up our instance, all we have to do is load that file into memory and then we have tons of read-only data in just a few ms.