【要約】S3時代のファントムファイル [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が、DBのレコードとS3のオブジェクトを同期させる際に、両システムを跨ぐトランザクションが存在しないという問題に直面する。このため、処理の途中でエラーが発生すると、必ずどちらかの不整合が生じる。\n\n・削除時：DBの行は消えたが、S3に実体が残る（孤児オブジェクト）。\n・削除時：S3の実体は消えたが、DBに参照が残る（壊れたリンク）。\n・アップロード時：S3に実体はあるが、DBに登録されない（孤児オブジェクト）。\n・アップロード時：DBに登録されたが、S3への書き込みに失敗する（壊れたリンク）。
// Approach
開発者は、不整合が発生した際の被害を最小化するため、処理の順序を制御する設計を採用する。具体的には、ユーザー体験を損なう「壊れたリンク」ではなく、コスト増に留まる「孤児オブジェクト」が発生するよう、実行順序を意図的に操作する。\n\n・削除処理：DBのトランザクションを先に完了させ、S3の削除は後続で行う。\n・アップロード処理：S3への書き込みを先に完了させ、DBへの登録を最後に行う。\n・署名付きURL利用時：未確定レコードを作成し、確定APIでHeadObjectを用いて実体を検証する。\n・運用面：定期バッチやS3ライフサイクルルールを用いて、孤児オブジェクトを回収する。
// Result
この設計により、システムはユーザーに壊れたリンクを見せることなく、管理可能な不整合状態を維持できる。\n\n・ユーザー体験の向上：DBを正とすることで、実体のない参照をユーザーに露出させない。\n・運用の定型化：不整合を「ガベージコレクション（GC）」の問題として捉え、バッチやライフサイクルルールで機械的に解決する。\n・設計の単純化：完璧な整合性を追わず、失敗時の挙動を「孤児側」に倒すことで、コードの複雑性を抑えられる。
Senior Engineer Insight
> 分散システムにおいて、完全な整合性を追求することはコストと複雑性を増大させる。本記事が示す「被害の小さい方に倒す」という設計思想は、可用性と運用コストのトレードオフを最適化する極めて実践的な判断だ。特に、S3のライフサイクルルールや定期バッチによるGCを前提とした設計は、エラーを「異常」ではなく「想定内の状態」として扱う、プロフェッショナルな設計手法と言える。