这是一道极具 Stripe 业务特色的题目，背景设定在巴西的支付监管环境。它考察的是候选人对状态管理、时间线重叠处理以及复杂业务逻辑建模的能力。
题目描述
在巴西，当商户通过信用卡收款时，这笔未来的收入（Receivable）可以作为资产进行注册或交易。Stripe 需要根据监管要求，向中央注册机构（Registry）汇报这些应收账款。
Part 1: 注册应收账款 (Register Receivables)
给定一笔交易，你需要将其转化为“应收账款单元”。 通常一笔交易（Charge）包含：
amount: 金额payout_date: 预计打款日期status: 状态（如 pending, paid）
你需要实现一个函数，将 Charge 注册到 Registry。如果注册成功，Registry 会返回一个唯一的 receivable_id。
Part 2: 合约与更新 (Contracts & Updates)
商户可能会与银行签署“预支合约”（Prepayment Contract），将未来的应收账款抵押给银行以换取现金。 这就引入了**“锁”**的概念：一旦某笔 Receivable 被合约锁定，Stripe 就不能随意修改它（例如不能更改打款日期或金额），除非先更新或取消合约。
输入流：
Charge Updates: 交易金额或日期发生变化。Contract Events: 商户签署或取消了合约。
挑战： 当收到一个 Charge Update 时，你需要检查该 Charge 对应的 Receivable 是否被任何 Active Contract 覆盖。
- 如果无合约：直接更新 Registry。
- 如果有合约：拒绝更新，或者按照特定逻辑（如拆分 Receivable）来处理。
oavoservice 解题思路分析
这道题的难点在于数据一致性和状态检查。
1. 实体关系建模
建议定义清晰的类结构：
class Charge:
id: str
amount: int
payout_date: str
class Receivable:
id: str # Registry 返回的 ID
charge_id: str
amount: int
status: str
class Contract:
id: str
target_charge_ids: List[str]
status: str # ACTIVE, CANCELLED
2. 冲突检测逻辑
处理 Charge Update 时，必须进行“前置检查”（Pre-check）：
- 根据
charge_id找到关联的receivable_id。 - 查询
ContractRepository，看是否存在status == ACTIVE且包含该receivable_id的合约。 - 关键点：注意合约的时间范围。有些题目变种是合约只锁定特定时间段内的应收账款。
3. 幂等性与重试
与 Registry 的通信可能会失败。面试官可能会问：如果调用 Registry 超时了怎么办？
- 解决方案：引入“状态机”或“重试队列”。在数据库中记录
PENDING_REGISTRY状态，通过后台 Job 重新提交。
觉得业务逻辑太复杂？
Stripe 的面试题往往充满“业务细节陷阱”。oavoservice 的导师团队均来自一线大厂，我们深知如何将这些复杂的业务需求拆解为简单的 CRUD + 状态检查代码。
- 场景模拟：还原真实的 API 交互流程。
- 代码精简：教你如何写出既满足需求又不超过 50 行核心逻辑的优雅代码。