Jiahe's Blog

Some time ago fwmcbaubau.com experienced data loss multiple times in a short time span due to the lack of persistent storage.

The data was stored in a self-hosted Redis server because it was cheaper to provision a Redis server with extra resources rather than utilize the SaaS version. When I first developed the feature I didn’t provision any storage for the pod because of the added complexity and cost. When the first data loss incident occurred, I looked into the costs of provisioning storage and concluded that it was reasonable. However, restoring the data wasn’t a big deal and enough time had passed that I didn’t feel like modifying the deployment. The recent incidents finally got me to take action because it took me a while to notice the first and the second one happened really soon after the first.

Before we begin, check out the site at fwmcbaubau.com!

In case you didn’t visit the site or came from a future where the site is no longer live, here’s a brief description.

fwmcbaubau.com is a website where users contribute to a global click count by clicking on a button which also plays an animation and audio.

Architecture

Now that we’re on the same page, I’ll share the architecture of the site. The site itself is statically hosted, with the assets coming from a CDN.

This is a follow up post to the one I made about the TTGO T5 v2.2. The aim was to prepare images and make them available for display.

Background

At this point I had a Lambda function for converting image data to binary data directly usable by the epdiy Arduino library using Pillow.

I also explored taking screenshots of webpages using Puppeteer, uploading them to S3 and passing them through the Lambda function. However, I had a few concerns about this approach: