<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Lifecycle on Momo Engineering Journal</title><link>/tags/lifecycle/</link><description>Recent content in Lifecycle on Momo Engineering Journal</description><image><title>Momo Engineering Journal</title><url>/images/og-image.png</url><link>/images/og-image.png</link></image><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 28 Oct 2026 17:47:15 -0600</lastBuildDate><atom:link href="/tags/lifecycle/index.xml" rel="self" type="application/rss+xml"/><item><title>S3 Lifecycle Rules on a Content-Addressed Store: Time as a First-Class Dimension</title><link>/posts/058-s3-lifecycle-on-cas/</link><pubDate>Wed, 21 Oct 2026 03:35:13 +0000</pubDate><guid>/posts/058-s3-lifecycle-on-cas/</guid><description>Lifecycle rules are the first feature that makes momo delete data on a schedule rather than on request — which turns age, storage class, and delete markers into correctness problems. This post walks through the expiration and transition engine, why a background worker is the only safe place to run it, and how expiration composes with versioning&amp;rsquo;s delete markers.</description></item></channel></rss>