Could definitely have used Dynamo as a persistent layer, but the PNGs are transient - the definition is stored in a GitHub gist owned by the user (another free tier! :). But generating the PNGs is expensive, so they get cached in S3. An S3 lifecycle rule automatically prunes PNGs older than a month, and they'll get regenerated from the gist if needed.
A month seems like a long time, I’d have assumed you could probably delete 95% of the images within 3 days. Out of interest is the month long expire rule a guesstimate or something based on actual numbers?
It's just a number, I haven't looked at any request logs to see what hit rates are like.
From a money perspective, expiring them never would be fine, and a good trade off to get better latency on subsequent loads. However, if the underlying gist is deleted, I'd like the PNG to eventually go away.
Comments
Nice. I assume you are hosting PNGs for 'get embed code' feature?
Could you instead store diagram definition in DynamoDB free tier, and create PNGs on the fly?
Yeah, it's for get embed code.
Could definitely have used Dynamo as a persistent layer, but the PNGs are transient - the definition is stored in a GitHub gist owned by the user (another free tier! :). But generating the PNGs is expensive, so they get cached in S3. An S3 lifecycle rule automatically prunes PNGs older than a month, and they'll get regenerated from the gist if needed.
A month seems like a long time, I’d have assumed you could probably delete 95% of the images within 3 days. Out of interest is the month long expire rule a guesstimate or something based on actual numbers?
It's just a number, I haven't looked at any request logs to see what hit rates are like.
From a money perspective, expiring them never would be fine, and a good trade off to get better latency on subsequent loads. However, if the underlying gist is deleted, I'd like the PNG to eventually go away.