##### Question Implement `mergeCustomers(String oldId, String newId)` for a payments/ledger platform. The call absorbs `oldId` into the survivor `newId` while preserving every account's balance and complete, immutable transaction history. Accounts are not coalesced — each account, with its history and balances, stays attached to its own account id. Design the full merge and explain your reasoning for each of the following: 1. **Identifier unification** — How do you unify the two identities so that, from the moment of merge commit, both `oldId` and `newId` resolve to a single canonical identity for all reads and future writes? 2. **Ownership remap** — How do you reassign ownership metadata across the entities that reference a customer (accounts, payment instruments, transfers, beneficiaries, etc.) without rewriting the ledger? 3. **Re-link historical and scheduled items** — How do you re-link historical payments/transfers and recurring/scheduled items so nothing is lost or double-executed? 4. **Pending / held items** — How do pending or held transactions, authorizations, and in-flight transfers continue to settle correctly after the merge? 5. **Conflict & duplicate resolution** — How do you handle `customerId` collisions and uniqueness conflicts (e.g. duplicate payment methods on the same token, identical scheduled items, beneficiary collisions, single-primary constraints, per-customer unique nicknames)? Give deterministic policies. 6. **Indexes & caches** — How do you update or invalidate indexes and caches, including the **top-N payers / top-N spenders** structure, so leaderboards stay correct immediately after the merge? 7. **Post-merge query correctness** — How do balances, transaction history, and top-N aggregates remain correct (no loss, no double-counting) for queries issued by either id? 8. **Atomicity & consistency** — What are your atomicity and system-wide consistency guarantees? How do you make the operation idempotent (repeating a merge is a no-op) and safe under concurrent merges (including chains A→B then B→C)? 9. **Complexity** — Analyze time and space complexity of the merge and of the post-merge read path.

A Meta software-engineer system-design take-home: implement mergeCustomers(oldId, newId) for a payments/ledger platform, absorbing one customer into another while preserving every account's balance and immutable transaction history. Tests identity unification, ownership remap, conflict/duplicate resolution, top-N leaderboard maintenance, atomicity, concurrency, idempotency, and complexity analysis.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Take-home Project rounds at Meta.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Meta during technical interviews.

Merge customers and preserve history | Meta Interview Question

Question

Implement mergeCustomers(String oldId, String newId) for a payments/ledger platform. The call absorbs oldId into the survivor newId while preserving every account's balance and complete, immutable transaction history. Accounts are not coalesced — each account, with its history and balances, stays attached to its own account id.

Design the full merge and explain your reasoning for each of the following:

Identifier unification — How do you unify the two identities so that, from the moment of merge commit, both oldId and newId resolve to a single canonical identity for all reads and future writes?
Ownership remap — How do you reassign ownership metadata across the entities that reference a customer (accounts, payment instruments, transfers, beneficiaries, etc.) without rewriting the ledger?
Re-link historical and scheduled items — How do you re-link historical payments/transfers and recurring/scheduled items so nothing is lost or double-executed?
Pending / held items — How do pending or held transactions, authorizations, and in-flight transfers continue to settle correctly after the merge?
Conflict & duplicate resolution — How do you handle customerId collisions and uniqueness conflicts (e.g. duplicate payment methods on the same token, identical scheduled items, beneficiary collisions, single-primary constraints, per-customer unique nicknames)? Give deterministic policies.
Indexes & caches — How do you update or invalidate indexes and caches, including the top-N payers / top-N spenders structure, so leaderboards stay correct immediately after the merge?
Post-merge query correctness — How do balances, transaction history, and top-N aggregates remain correct (no loss, no double-counting) for queries issued by either id?
Atomicity & consistency — What are your atomicity and system-wide consistency guarantees? How do you make the operation idempotent (repeating a merge is a no-op) and safe under concurrent merges (including chains A→B then B→C)?
Complexity — Analyze time and space complexity of the merge and of the post-merge read path.

Question

Design the full merge and explain your reasoning for each of the following:

Identifier unification — How do you unify the two identities so that, from the moment of merge commit, both oldId and newId resolve to a single canonical identity for all reads and future writes?
Ownership remap — How do you reassign ownership metadata across the entities that reference a customer (accounts, payment instruments, transfers, beneficiaries, etc.) without rewriting the ledger?
Re-link historical and scheduled items — How do you re-link historical payments/transfers and recurring/scheduled items so nothing is lost or double-executed?
Pending / held items — How do pending or held transactions, authorizations, and in-flight transfers continue to settle correctly after the merge?
Conflict & duplicate resolution — How do you handle customerId collisions and uniqueness conflicts (e.g. duplicate payment methods on the same token, identical scheduled items, beneficiary collisions, single-primary constraints, per-customer unique nicknames)? Give deterministic policies.
Indexes & caches — How do you update or invalidate indexes and caches, including the top-N payers / top-N spenders structure, so leaderboards stay correct immediately after the merge?
Post-merge query correctness — How do balances, transaction history, and top-N aggregates remain correct (no loss, no double-counting) for queries issued by either id?
Atomicity & consistency — What are your atomicity and system-wide consistency guarantees? How do you make the operation idempotent (repeating a merge is a no-op) and safe under concurrent merges (including chains A→B then B→C)?
Complexity — Analyze time and space complexity of the merge and of the post-merge read path.

Merge customers and preserve history

Quick Overview

Merge customers and preserve history

Question

Submit Your Answer to Earn 20XP

Merge customers and preserve history

Quick Overview

Merge customers and preserve history

Question

Submit Your Answer to Earn 20XP