少なくとも一度の配信

Outcome：Complete the task with 少なくとも一度の配信 (At-Least-Once Delivery)。 User context：ワーカーはレシート `evt-42` を保存しますが、Amazon SQSメッセージを削除する前に停止します。SQSは後で同じメッセージを再び配送します。次のワーカーは保存されたイベントIDを確認し、2つ目のレシートを作成する代わりに既存のレシートを返します。 Technical concept or control：少なくとも一度の配信 (At-Least-Once Delivery)。 Why it fits：仕事を一度失う方が二度処理するよりも悪い場合、このルールを使用してください。すべてのメッセージに安定したIDを付与します。繰り返しのメッセージは、二重に課金、メール送信、保存されてはいけません。 Do not use it when：配信は作業が成功したことを意味しません。正確に1つの結果を約束しないでください。料金や外部の操作には独自の重複防止が必要です。 Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary)：単一の公式標準が全体の用語を管理するわけではありません。その意味はチーム、プラットフォーム、またはフレームワークによって変わる可能性があります。 Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.