問い合わせの送信結果が分からないとき、どう扱うか

問い合わせ基盤は、本体と必要な配信予定を同じトランザクションで保存します。本体だけ残って通知の仕事が消える、といった片側だけの成立を避けるtransactional outboxの考え方です。

確認した受付処理と契約テストでは、同じ送信識別子と同じ内容の再試行には保存済みの受付を返し、新しい配信予定を増やさない経路を扱います。同じ識別子で内容が違えば同じ送信と扱わず、保存できなかった場合も成功にしません。

HTTPには冪等性の概念がありますが、通常のPOSTを繰り返せば同じ一件になると保証されるわけではありません。新規受付では、アプリケーションが同じ送信を識別して既存結果へ戻す契約を持つ必要があります。

Firestoreの公式文書は、競合時にトランザクションが再実行され得ると説明しています。その中でメール送信のような外部作用を実行すると、保存のやり直しに伴って繰り返す危険があります。保存するのは通知の予定で、配送は後に分けます。

workerは保存された予定を取り出し、結果を記録して失敗を再試行します。しかし外部の送信先が受け取った直後に応答が消えれば、配送結果も曖昧になります。受付の重複防止とメールのexactly-once保証は別です。

PBGの設計は配信状態と回復経路を持ち、滞留を監視する責任を残します。イベントと補完処理の二経路から、定期取得を中心にする方式へ絞った決定もあります。即時性と複雑さを比べ、必要な待ち時間に合う方式を選ぶ判断です。

既存フォームサービスが必要な受付管理・重複対策・会社分離・保持方針を満たすなら利用する価値があります。メール送信だけでよいか判断するときも、通知が失敗した受付をどこから回復できるかは確認します。

独自基盤には保存、配送、監視、保持・削除の保守責任が増えます。公開したい知見は構成の大きさではなく、「受け付けた」という言葉を失われない事実へ結び付けることです。