決済の通知が、二回届いたことがある。
一件の支払いなのに、システムには二つの通知が来た。あやうく、同じ成果物を二つ作り、二重に請求しかけた。決済の世界では、こういうことが普通に起きる、と後で知った。通知は、一回だけ来るとは限らない。その前提が、私には抜けていた。
通知は、一回とは限らない
外のサービスからの通知は、遅れたり、前後したり、二度届いたりする。
ネットワークの都合で、同じ通知が再送されることもある。順番が入れ替わることもある。これを「一回だけ、順番どおりに来る」と思って作ると、必ずどこかで破綻する。届く回数も、順番も、信用しない。そこから作り直した。
二度目は、そっと無視する
そこで、同じ通知が二度来ても、結果が変わらないようにした。
通知には、それぞれ目印をつけておく。一度処理した目印が、また来たら、二度目は何もしない。成果物を作るのも、請求を立てるのも、一度きり。同じ注文から、成果物は一つしか生まれない。二度叩かれても、一度ぶんの結果に落ち着く。この「二度来ても平気」を、あちこちに効かせた。
本物の通知かを、確かめる
二重処理を防ぐ前に、そもそも、その通知が本物かも確かめる。
決済サービスからの通知には、署名がついている。その署名を検証して、確かにあのサービスから来たものだと分かってから、初めて処理する。署名が合わなければ、受け付けない。偽の通知で、成果物を勝手に出させない。入口で、なりすましを弾く。
順番が前後しても、壊れない
二度来るだけでなく、順番が入れ替わることもあった。
契約より先に、その契約の更新の通知が届く。そんな、ありえない順番が、外の世界では起きる。だから、対象ごとに版の番号を持たせて、古い通知が後から来ても、新しい状態を上書きしないようにした。届いた順ではなく、本来の順で、状態を決める。来る順番も、信用しない。
中途半端な状態を、残さない
処理の途中で止まったときのことも、考えた。
導入の設定や、外部との接続は、途中で失敗することがある。そのとき、半分だけできた中途半端な状態が残ると、後が厄介になる。だから、各ステップは、何度やり直しても同じ結果になるようにして、失敗したら、きれいに元へ戻せるようにした。やりかけを、放置しない。
決済も、通知も、外の世界はこちらの都合では動かない。その前提で、二度来ても、途中で落ちても、壊れない作りにする。地味だが、無人で回す土台は、こういう細部でできている。
次の回は、止めること、消すこと——終わり方の設計について書く。