Design: mergeCustomers(oldId, newId) for a Payments Platform

Context

You are building a banking/payments system with the following high-level entities:

• Customer: owns one or more Accounts; appears in payments, transfers, and scheduled items.
• Account: holds a balance and has immutable transaction history.
• Transaction: immutable ledger events tied primarily to an Account; may also reference a Customer for convenience/analytics.
• PaymentMethod, Transfer, ScheduledItem, Beneficiary, etc.: may reference a Customer and/or Account.

A customer merge happens when two profiles are determined to be the same person. You must merge Old (oldId) into New (newId) while:

• Preserving each Account’s balance (Accounts are not merged or summed) and full transaction history.
• Unifying identifiers so the system treats the merged identity as one Customer.
• Re-linking historical and scheduled items correctly.
• Resolving conflicting or duplicate references deterministically.
• Ensuring post-merge queries (balances, histories, top-N spenders) remain correct.
• Analyzing complexity and consistency guarantees.

Assume oldId ≠ newId and both exist.

Task

Design mergeCustomers(String oldId, String newId):

1. Define how identifiers are unified and how reads/writes should behave immediately after merge.
2. Specify how to re-link historical records (payments/transfers/scheduled items) without losing data.
3. Describe conflict/duplicate resolution rules and data structures used to record superseded items.
4. Ensure post-merge queries remain correct for balances, transaction histories, and analytics (e.g., top-N spenders).
5. Provide complexity analysis (time/space, online overhead) and consistency guarantees (atomicity, isolation, idempotency, failure handling).
6. Include any minimal schema additions you need (e.g., alias tables, status fields) and an outline of the merge algorithm.