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

小さなフォームは、受け取った内容をそのままメールで送るだけでも動きます。しかしメールサービスが遅い、送信途中で処理が落ちる、迷惑メール判定で届かないといった失敗を、問い合わせの消失と区別できません。

問い合わせ基盤では、受け付けた内容を耐久性のある保存先へ記録し、その事実を確定してから後続処理へ進める設計を採っています。メールは重要な通知ですが、受付の正本ではありません。

受付を保存した後、「通知待ち」を作る前に処理が落ちれば、保存はあるのに誰も気付けません。反対に通知を先に送り、その後の保存に失敗すれば、担当者が見た内容と正式記録がずれます。

そこで受付と通知待ちの記録を一つの取引として確定し、通知処理は後からその記録を読みます。これがtransactional outboxの考え方です。通知に失敗しても、受付をやり直さず通知だけを再試行できます。

同じ人が同じ文章を二度送ることもあります。本文が同じという理由で片方を消せば、正当な二件を一件にしてしまいます。

ブラウザ側で一つの送信試行に識別子を付け、通信を再試行しても同じ識別子を使います。サーバーは同じ識別子なら同じ受付結果を返します。これにより、応答が失われても再試行を二重受付へしない、冪等な処理にできます。

通知を別処理にすれば受付は守れますが、滞留を見つけられなければ問い合わせへの対応は遅れます。再試行回数、次の実行時刻、最終的に人へ知らせる状態、重複通知を防ぐ記録が必要です。

外部サービスの障害中は待ち、復旧後に再開する。永続的なエラーなら無限に回さず、理由と受付を残して運用者へ渡す。回復経路まで含めて初めて、非同期化が信頼性になります。

利用者が送信操作をしたこと。サーバーが受け付けたこと。通知が担当者へ届いたこと。担当者が対応を始めたこと。これは別の出来事です。

小規模な窓口で、停止時は電話へ切り替えられるなら、ここまでの仕組みが常に必要とは限りません。ただし「絶対に失いたくない」「利用者が安全に再試行できる」「通知障害から回復したい」という条件があるなら、メール送信成功ではなく受付事実から設計を始めます。

送信ボタンを押してから、受付を保存し、担当者へ知らせ、ブラウザへ応答を返すまでには複数の区間があります。保存の直後に通信が切れれば、利用者には失敗と見え、サーバーには受付が残ります。通知だけが失敗すれば、受付はあるのに誰も気付きません。メールが届いたかだけでフォームの信頼性を測れない理由はここにあります。

最初に守るのは、問い合わせを受け付けた事実です。その事実を永続的に残し、通知や後続処理は別に回復できる形で扱います。同じ送信を再試行したときは、本文が似ているからではなく、同じ依頼だと識別できる情報で重複を防ぎます。確定できないときは、成功とも失敗とも断定せず、受付を確認できない状態として扱います。

ピース・ビズ グループの問い合わせ基盤では、永続受付、後続通知の分離、再試行、冪等性を設計・実装しています。現在の公開フォームがその基盤へ接続済みという意味ではありません。記事で扱うのは、フォームを作る前に、何を失ってはいけないかを分ける考え方です。