在进入架构之前,让我先把一件事说清楚:这个角色结束,是因为业务部门在一次战略重组中被关闭了。不是因为 Mo 搞砸了什么。系统运行良好。Fintech 就是这么奇怪——你可以交付出色的基础设施,然后眼睁睁看着组织架构图在你脚下折叠。好了。说真正有意思的部分。

“Event-driven 信用评估”——停止客气之后它的意思

以下是它出现在每个 fintech 招聘描述里的版本:“在 event-driven 架构中进行高吞吐量交易处理。“以下是它在一个做严肃体量的贷款 marketplace 里实际意味着什么:

借款人提交一份申请。那份申请不是数据库里一行、等着 cron job 最终处理的记录。它立即就是一个事件,而一群下游服务在等它:信用评分 pipeline、欺诈检测层、监管报告钩子、合作贷款机构路由逻辑。每一个都是它自己的领域,每一个都有自己的失败模式,而要求是它们互相都不阻塞。happy path 要工作。不那么 happy 的路径——信用局调用超时、被限流的合作贷款机构 API——必须被处理,而借款人完全不知道发生了什么。

Kafka 是这里的骨干,因为你需要持久性、重放和独立的消费者进度。信用局调用失败了?你的消费者从提交的 offset 以干净状态重试。你需要重放三天的事件,因为一个下游服务有 bug?回退消费者。你需要入驻一个新的合作贷款机构,它需要处理已经发生的事件?再次重放。这就是这个领域的团队选择 Kafka 而不仅仅是消息队列的原因:队列会忘记,Kafka 会记得。

监管约束塑造了下游所有的东西

Fintech 基础设施不只是一个调用外部服务的 API。每一个决策——每一个贷款报价、每一个信用额度、每一个拒绝——都必须是可解释的。这在德国和整个欧盟不是可选项,而是法律要求。GDPR、BaFin、消费者信贷指令。审计追踪不是锦上添花;它是产品。

这改变了你如何设计事件 pipeline。你不能只是处理然后忘记。事件需要是不可变的、有归属的、可检索的。信用工作流里的事件 schema 在某些情况下携带的元数据比 payload 更多——谁发起了决策、查阅了哪个模型版本、触发了哪条规则、做出决策时输入数据是什么样子。这些全部必须保存多年。

在 Kubernetes 上这意味着你还在思考消费者侧的 exactly-once 语义、幂等处理器,以及那种被实际监控而不是默默积累直到有人注意到告警被静音了的死信队列。问我见过多少个被当作只写存储的死信队列。

在受监管后端交付 AI/LLM 自动化是个不同的问题

以下是大多数会议演讲里缺失的关于金融服务 AI 集成的东西:模型不是难的部分。让 LLM 自动化通过合规审查、进入生产 pipeline、在受监管的金融环境里——那才是难的部分。

我在 auxmoney 做这个工作时,挑战不是能力。现代 LLM 在文档理解、分类、从非结构化输入提取结构化数据方面是真正有用的。挑战是治理。你如何解释一个 LLM 辅助做出的决策?你如何版本化模型,使得一月份做出的决策在十月份监管机构询问时可以被重现和解释?你如何测试模型的输出是被用作人工干预流程里的信号,而不是完全自动化的流程——这件事是如何被记录的?

答案涉及大量对用户不可见的工程。信用工作流里的模型调用不是一个原始 API 调用;它是一个版本化的、有日志的、可审计的调用,使用的是固定到特定模型版本的稳定 prompt 模板,输出和决策记录一起存储。LLM 成为可审计 pipeline 里的一个组件,而不是你调用然后忘掉的黑盒。这比大多数团队在消费者 app 里做的更保守,也应该如此。风险不同。

在遗留 PHP + Java codebase 里当 Playing Captain

“作为 Playing Captain 深度参与 codebase”的企业语是:我是一个同时写代码、review 代码、在东西着火时修复东西的首席架构师。在一个已经运行了十年的 fintech codebase 里,这意味着驾驭实际存在的考古现场。Kubernetes 迁移之前就有的 PHP 服务,坐在 Kafka 采用之前就有的 Java microservices 旁边,旁边是有人上个季度写的全新 Go 工具。

架构工作和既有代码的现实是不可分的。你没法设计一个漂亮的新 event-driven 信用 pipeline,而不考虑那个是借款人状态当前 source of truth 而且这个季度不会被重写的 PHP 服务。所以你构建 adapter,从遗留系统的边界发布领域事件,在 Kafka topic 层定义契约,让每个服务拥有自己的实现。这不是光鲜的工作。这是唯一真正能发布的工作。

底层全是 AWS:Kubernetes 工作负载用 EKS,托管 Kafka 用 MSK,需要是关系型的关系状态用 RDS。基础设施不奇特。问题在领域里,不在技术栈里。

这类工作实际上给你留下什么

做得对的贷款基础设施是我工作过的技术上最严格的领域之一。高交易量、严格 latency 要求、监管可解释性,以及搞错的财务后果这些的组合,产生了我在不多的其他环境里见过被复制的工程纪律。

我在医院规模交付过医疗系统(EHR、药房配发、临床工作流),构建过消费者 app,做过企业集成考古。Fintech 信用基础设施坐在一个特定的类别里:它在每一层都惩罚粗心,而当你做对了,你构建出来的东西是真正健壮的。业务部门被关闭不改变组织架构图改变之前系统在做什么。

我目前在 W-2 席位之间,做 Fulcrum 的开源工作——一个 local-first 的 agent 控制面——以及咨询。如果你在构建 event-driven 金融基础设施并且想聊架构,你知道在哪里找我。