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

Quick Overview

This question evaluates a candidate's competency in system design, data modeling, distributed consistency, transactional integrity, and failure-resilient schema evolution required to merge customers and preserve immutable transaction histories in a payments platform.

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):

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

Quick Overview

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):

Define how identifiers are unified and how reads/writes should behave immediately after merge.

Specify how to re-link historical records (payments/transfers/scheduled items) without losing data.

Describe conflict/duplicate resolution rules and data structures used to record superseded items.

Ensure post-merge queries remain correct for balances, transaction histories, and analytics (e.g., top-N spenders).

Provide complexity analysis (time/space, online overhead) and consistency guarantees (atomicity, isolation, idempotency, failure handling).

Include any minimal schema additions you need (e.g., alias tables, status fields) and an outline of the merge algorithm.

Merge customers and preserve history

Quick Overview

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

Context

Task

Solution

Submit Your Answer

Merge customers and preserve history

Quick Overview

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

Context

Task

Solution

Submit Your Answer