非同期処理においてデータの整合性を保つアーキテクチャパターン - inSmartBank

この記事はSmartBank Advent Calendar 2024 6日目の記事です。 昨日は kassy さんの「成長するスタートアップ労務の醍醐味と挑戦をUXリサーチャーが聞いてみた！」という記事でした。 はじめに サーバーサイドエンジニアの mokuo です。普段は、カード決済やあとばらいチャージに関連する機能の開発や運用を行っております。 本日は、サーバーサイドエンジニア向けの記事になります。 本記事でお話しすること システムには断続的に行われる一連の処理、というものがあります。この中で非同期処理を行うこともあるでしょう。 例) EC サイトにおける注文処理のワークフロー このような機能を開発・運用していると、以下のような課題に直面することがあります。 処理の流れが把握し辛い 変更を行うのが困難 データの整合性を担保するのが難しい しかし、適切に設計を行うことで、これらの課題を

[kkobayashi]

ステートマシンならともかく順番が決まってるならイベント同士を繋げる必要ない気がするんだけど（要はパターン2でいいじゃんという）

[lanius]

イベントID、Transactional outboxパターン。

[sasamuku]

「メッセージ送信成功後にコミット失敗」ではない？ >メッセージ送信に失敗した場合は DB トランザクションがロールバックされるが、メッセージ送信に失敗した後に、DBトランザクションのコミットに失敗する可能性

[sulky]

順番が決まってるなら複雑にしなくてもいい見えない何かあがあるのでしょう

[yasushicohi]

アーキテクチャパターン、マイクロサービス

[phain]

やっぱり大がかりな仕組み化が必要なのか。

[matarillo]

よくまとまってると思います

[prograti]

リアルタイムでロールバックする必要がないのならシンプルにバッチで中断ポイントからリトライでも良さそう。リトライ不可のエラーならしょうがないけど

[c-matt]

イベントソーシングの文脈でよく出てくるやつ。Greg Youngのだと「起因となったイベントのID」、「一つ前の処理のID」、「現在の処理のID」の3つを含むようにしてるんだけど途中でパラになったりするとちょっと面倒

[turanukimaru]

イベントIDで管理してトランザクションを取り消すときは全部を取り消すのが良いと思う。前のアクションのIDを保持するのは…あーその頃はイベント駆動って概念が無かったのか。

[yojik]

イベント前後をピンポイントでとる要求がよくわからない(一括ジョイン&ソートでいいのでは...)が、パターン4+先行アクティビティのFK持たせて再帰構造にするのが教科書的な正解なのかな。(本文でも触れらていたけど)

[Iridium]

異常系に弱くない？2つ戻らないといけない場合とか普通にあるよね。転居しててカードが届かなかったらどうなるんだろう。抽象的すぎてよくわからない

[ohbarye]

"アーキテクチャや設計を見直すことで、開発コストや運用コストを大幅に改善することも可能だと考えています。これは当然、事業スピードの成長に繋がるでしょう。"

[mokuoz]

一連のイベント(出来事)からなる業務フローの、開発・運用に関する辛みを解決する設計パターンについてまとめました。部分的に取り入れるだけでも効果が期待できるような構成になるよう意識しました。