這是一道極具 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 行核心邏輯的優雅程式碼。