アーキテクチャに入る前に一つ正直に言っておく：そのロールは事業部門が戦略的な再編成で閉鎖されたために終わった。Moが何かを壊したからではない。システムは問題なく動いていた。フィンテックはそういうものだ — 優れたインフラを出荷して、組織図が自分の下で折り畳まれるのを見ることができる。まあいい。本当に面白い部分に入ろう。

礼儀正しくするのをやめたとき「イベント駆動の信用評価」が何を意味するか

すべてのフィンテックの求人票に現れるバージョンはこうだ：「イベント駆動アーキテクチャでの高ボリュームトランザクション処理」。真剣なボリュームをやっているローンマーケットプレイスで実際に何を意味するかはこうだ：

借り手がアプリケーションを送信する。そのアプリケーションはいつまでもcronジョブが拾うデータベースの行ではない。それはイベントで、即座に、そしてダウンストリームサービスのクラスターが待っている：信用スコアリングパイプライン、不正検知レイヤー、規制報告フック、パートナーレンダールーティングロジック。それぞれが独自のドメインで、独自の失敗モードを持ち、要件はそれらのどれも他をブロックしないことだ。ハッピーパスは機能しなければならない。アンハッピーパス — 信用局の呼び出しでのネットワークタイムアウト、スロットリングしたパートナーレンダーAPI — は借り手が何も起きていないことに気づかずに処理されなければならない。

Kafkaがバックボーンだ。なぜなら耐久性、リプレイ、独立したコンシューマーの進捗が必要だからだ。信用局の呼び出しが失敗した？コンシューマーはクリーンな状態でコミットされたオフセットからリトライする。ダウンストリームサービスにバグがあったから三日分のイベントをリプレイする必要がある？コンシューマーを巻き戻す。すでに起きたイベントを処理する必要がある新しいパートナーレンダーをオンボードする？またリプレイ。これがこのスペースのチームがメッセージキューだけではなくKafkaに手を伸ばす理由だ：キューは忘れ、Kafkaは記憶する。

規制の制約がダウンストリームのすべてを形成する

フィンテックインフラは外部サービスを呼び出すだけのAPIではない。すべての決定 — すべてのローンオファー、すべてのクレジットリミット、すべての拒否 — は説明可能でなければならない。これはオプションではなく、ドイツとEU全体での法的要件だ。GDPR、BaFin、Consumer Credit Directive。監査証跡はあったら良いものではない。それはプロダクトだ。

これがイベントパイプラインの設計方法を変える。処理して忘れるだけはできない。イベントはイミュータブルで、属性付きで、取得可能でなければならない。信用ワークフローのイベントのスキーマは、場合によってはペイロードよりも多くのメタデータを持つ — 誰が決定を開始したか、どのモデルバージョンが参照されたか、どのルールが発火したか、決定がなされたときの入力データがどんな様子だったか。そのすべてが何年も生き残らなければならない。

Kubernetes上では、コンシューマー側での厳密に一回のセマンティクス、冪等ハンドラー、そして誰かがアラートがミュートされたことに気づくまで静かに積み上がる種類ではなく実際にモニタリングされているデッドレターキューについても考えている。書き込み専用ストレージとして扱われているデッドレターキューをいくつ見てきたか聞いてほしい。

規制されたバックエンドでAI/LLMの自動化を出荷することは別の問題だ

ほとんどのカンファレンストークから欠落している金融サービスでのAIインテグレーションについての事実はこうだ：モデルが難しい部分ではない。LLMの自動化をコンプライアンスレビューを通過させて、本番パイプラインの内部で、規制された金融環境で — それが難しい部分だ。

auxmoneyでこの作業をしていたとき、課題は能力ではなかった。モダンなLLMは文書理解、分類、非構造化入力からの構造化データの抽出に本当に役立つ。課題はガバナンスだった。LLMが支援した決定をどう説明するか？規制当局が10月に尋ねるとき、1月に下された決定を再現して説明できるよう、モデルをどうバージョン管理するか？モデルの出力がhuman-in-the-loopフローでシグナルとして使われているのか完全自動化されているのかをどうテストして、どう文書化するか？

答えはユーザーには見えない多くのエンジニアリングを含む。信用ワークフローのモデル呼び出しは生のAPI呼び出しではない。特定のモデルバージョンに固定された安定したプロンプトテンプレートを持つ、バージョン管理され、ログされ、監査可能な呼び出しで、出力は決定レコードと一緒に保存される。LLMは監査可能なパイプラインのコンポーネントになる。呼び出して忘れるブラックボックスではない。これはコンシューマーアプリのほとんどのチームがやることよりも保守的で、そうであるべきだ。ステークスが違う。

レガシーPHP + JavaコードベースでプレイングキャプテンをするPlay

「コードベースでプレイングキャプテンとして非常にハンズオン」は日本語で：私は本番コードを書き、コードをレビューし、燃えているときに物を直した主任アーキテクトだった。十年間動いているフィンテックコードベースでは、実際に存在するものの考古学をナビゲートすることを意味する。PHPサービスはKubernetesマイグレーション前から、JavaマイクロサービスはKafka採用前から、Goユーティリティは誰かが先四半期に書いたものが、隣り合っている。

アーキテクチャ作業は既存のコードの現実と切り離せない。レガシーシステムの借り手状態の現在の真実のソースであるPHPサービスを考慮せずに、美しい新しいイベント駆動の信用パイプラインを設計できない。今四半期にそれは書き直されない。だからアダプターを構築し、レガシーシステムの境界からドメインイベントを公開し、Kafkaトピックレベルでコントラクトを定義して各サービスが独自の実装を所有させる。これは派手な作業ではない。実際に出荷する唯一の作業だ。

その下にあるAWS：KubernetesワークロードのためのEKS、マネージドKafkaのためのMSK、リレーショナルである必要があるリレーショナル状態のためのRDS。インフラはエキゾチックではない。問題はドメインにあり、スタックにはない。

この種の作業が実際に残してくれるもの

正しくやった融資インフラは、私が取り組んできた最も技術的に徹底したドメインの一つだ。高トランザクションボリューム、ハードなレイテンシ要件、規制上の説明可能性、間違えることの財務的な結果の組み合わせが、他の多くの環境でこれほど多く見たことがないエンジニアリング規律を生み出す。

病院スケールのヘルスケアシステム（EHR、薬剤調剤、臨床ワークフロー）、コンシューマーアプリ、エンタープライズインテグレーションの考古学を出荷してきた。フィンテックの信用インフラは特定のカテゴリに座っている：あらゆるレイヤーで雑さを罰し、うまくやれば本当にロバストなものを構築している。事業部門が閉鎖されても、組織図が変わる前にシステムが何をしていたかは変わらない。

今はW-2を離れて、Fulcrum — ローカルファーストのエージェントコントロールプレーン — のオープンソース作業とコンサルティングをしている。イベント駆動の金融インフラを構築していてアーキテクチャについて話したいなら、どこで探せばいいかを知っている。