Migrate a Monolithic Wallet to Microservices
You run a high-scale consumer digital wallet with person-to-person payments — in the shape of Apple Cash — built as a monolith with one database. Plan its migration to microservices.
Define the service boundaries (for example identity and KYC, wallet, ledger, payments orchestration, risk and fraud, notifications); who owns which data and how it is migrated; API design and idempotency; how transactions that cross services work, and whether you would use sagas or two-phase commit; consistency and reconciliation; authentication and authorisation; PCI and PII compliance; observability; and the rollout strategy, including strangler routing, canaries and rollback.
Finish with a phased plan, the key risks, and the metrics that tell you the migration succeeded.
Hints
Hint 1
Draw boundaries around data ownership and rate of change, not around nouns. The ledger — immutable double-entry postings — is the one place money truth lives; everything else holds references to it.
Hint 2
A transfer between two wallets is a single atomic posting inside the ledger service, so it needs no distributed transaction. Sagas are for the legs that touch the outside world: card funding, bank cash-out.
Hint 3
Never dual-write money. Feed the new ledger from the monolith's change stream in shadow, reconcile until the books match continuously, then flip the writer per cohort behind a routing layer that can flip back.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.