What to Expect in the Mercury System Design Interview

Expect design questions based on Mercury's own product: moving money safely and recording it correctly. Mercury, which builds banking for startups on top of partner banks, does not publish its design questions, and candidate reports on this round are thin. Published interview guides describe a banking focused design round for some roles, and candidates report that the technical rounds mirror real work rather than puzzles.

Expect a problem about transfers, ledgers, cards, or fraud checks, where the interviewer grades correctness under failure more than raw scale. A design that can double charge a customer fails, however elegant it looks.

The Question Types

Money movement. Design the system that sends a payment from a Mercury account to an outside bank, which in the United States usually means ACH, a batch network that settles between banks over hours or days. The hard parts are retries, partner bank failures, and knowing the true state of a payment that is neither sent nor failed.

The ledger. A ledger is the record of every balance change, written once and never edited. Design a ledger that supports many accounts, instant balance reads, and a full audit trail, which means any balance can be explained by the history that produced it. The hard parts are concurrency, rounding, and reconciliation, which is the job of checking that your records match the partner bank's records.

Cards and spend controls. Mercury issues cards with spending limits and merchant locks, which restrict a card to one merchant. Design the authorization path: a purchase request arrives, and the system must approve or decline in well under a second. The hard parts are latency, stale limits, and what to do when a dependency is slow.

Risk and fraud signals. Mercury's job posts list a Risk product group, and the matching question asks you to design the system that scores a transaction or a new account for fraud. The hard parts are feature freshness, false positives that block real customers, and review queues for humans.

What the Interviewer Grades

Correctness comes first: every write that moves money must be idempotent, which means the same request, sent twice, produces one result. State the failure cases out loud: the partner bank times out, the database commits but the response is lost, the retry arrives after the original. Then explain how each case is handled, name your trade-offs plainly, and connect choices to the customer, because a founder whose payroll fails on a Friday does not care about your throughput number.

A Walkthrough: Design an Outbound Transfer System

Here is a high level plan for the signature question.

1. Requirements (5 minutes). Assume many business accounts, a customer who requests a transfer from the app, and a partner bank with a batch submission window. The money must leave once, never twice, and the customer must see a truthful status at every moment.

2. The data model. Store each transfer as a record with a state (created, submitted, settled, failed, or returned), and store every state change with a timestamp. Give each transfer a client generated key so that a repeated request maps to the same record.

3. The ledger write. When the transfer is created, write a hold against the balance in the ledger, and commit the hold and the transfer record in one transaction so that if either fails, both fail.

4. Submission to the partner bank. A worker collects submitted transfers and sends a batch to the bank, recording the batch id on each transfer before sending, and if the send times out, it checks the bank for that batch id before resending. Never resend on a timeout alone.

5. Settlement and returns. The bank later reports which transfers settled and which returned, and a worker reads those reports and moves each transfer to its final state. On settlement, convert the hold into a posted debit; on return, release the hold and notify the customer.

6. Reconciliation. Every day, compare your ledger totals with the bank's statement, and open a case for a human on any difference. Alert when the difference exceeds a small threshold.

7. Scale and safety. Partition the ledger by account and cache balances, but recompute from the ledger on any doubt. Rate limit the submission workers so that a bug cannot send the bank too many requests.

Common Mistakes in This Round

• Treating a transfer as one request. A transfer is a state machine whose state changes over several days, so design for the middle states, not only for success.
• No idempotency. Any retry path without a unique key can move money twice, and interviewers usually ask about this.
• Editing balances in place. A balance column with no history cannot be audited, so store events and derive balances.
• Ignoring the partner bank. Mercury depends on outside banks, so a design that assumes the bank is always fast and always up is unrealistic.
• Skipping the human. Fraud review, reconciliation breaks, and returned payments all need a queue for people, so mention it before the interviewer asks.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, databases, and caches, which every money system uses.
• Go deeper on failure handling. Advanced System Design Interview, Volume II covers replication, consensus, and consistency, which ledger questions test.
• Rehearse the transfer walkthrough. Practice the seven steps above out loud in under 40 minutes.
• See the full loop. The design conversation is one part of the Mercury interview process, next to the motivation question, and wait times are in How long does it take to hear back after a Mercury interview.