Design a Digital Wallet: System Design Interview Walkthrough (2026)

When an interviewer asks you to design a digital wallet, they are looking for how you translate a familiar product into a clean, scalable architecture. The conversation usually starts with a high‑level description, then narrows down to the parts that are technically tricky. Below is a practical walkthrough that mirrors how senior engineers actually approach the problem.

1. Clarify the Scope First

Before you draw any boxes, ask a few clarifying questions. The goal is to pin down the exact problem the interviewee is expected to solve.

• What operations are in scope? Typical actions include adding funds, sending money to another user, withdrawing to a bank, and viewing transaction history. Some interviewers also add features like loyalty points or QR‑code payments.
• Who are the users? Individual consumers, merchants, or both? The presence of merchants introduces additional compliance and settlement flows.
• What regulatory environment? In many jurisdictions a wallet is considered a “money‑transmitter” and must satisfy KYC/AML checks. Knowing this early helps you decide where to place identity verification.
• Latency expectations? Real‑time balance updates are usually required for peer‑to‑peer transfers, while batch processing is acceptable for nightly settlement.
• Availability targets? A typical consumer‑facing service aims for "five‑nines" availability, but a prototype might tolerate lower SLAs.

These questions let you tailor the design and avoid spending time on irrelevant details.

2. Functional Requirements

These form the backbone of any digital‑wallet system.

3. Non‑Functional Requirements

• Scalability – Must handle spikes (e.g., holiday promotions) without degrading latency.
• Consistency – Strong consistency for balance queries; eventual consistency is acceptable for reporting.
• Durability – No loss of money; write‑ahead logs and double‑write to a ledger are common.
• Security & Privacy – End‑to‑end encryption, tokenization of card data, and strict access controls.
• Observability – Metrics for transaction latency, error rates, and fraud alerts.
• Regulatory – Ability to export audit logs and support data‑retention policies.

4. Core Domain Model

Think in terms of entities that map directly to business concepts.

User
  └─ Wallet (wallet_id, balance, currency)
        └─ Transaction (tx_id, type, amount, timestamp, status, counterpart_id)
        └─ CardLink (card_id, token, last4, expiry)
        └─ BankLink (bank_account_id, routing_number, status)

• User holds personal data and KYC status.
• Wallet is the ledger entry; balance is derived from the transaction stream, not stored as a mutable field.
• Transaction is immutable; each operation creates a new row.
• CardLink/BankLink store external payment instruments in a tokenized form.

5. API Sketch

A concise REST‑style (or gRPC) contract keeps the interview focused on business logic rather than transport details.

POST /users            → createUser(payload)
POST /wallets/{id}/add    → addFunds(walletId, amount, source)
POST /wallets/{id}/send   → sendMoney(walletId, recipientId, amount)
POST /wallets/{id}/withdraw → withdrawFunds(walletId, bankId, amount)
GET  /wallets/{id}/balance → getBalance(walletId)
GET  /wallets/{id}/txs    → listTransactions(walletId, cursor, limit)

Each endpoint validates inputs, checks limits, and returns a transaction ID that can be polled for status.

6. High‑Level Architecture

+-------------------+      +-------------------+      +-------------------+
|   API Gateway     | ---> |   Auth Service   | ---> |   Rate Limiter    |
+-------------------+      +-------------------+      +-------------------+
        |                         |                         |
        v                         v                         v
+-------------------+   +-------------------+   +-------------------+
|   Wallet Service |   |   Payment Service|   |   Fraud Service   |
+-------------------+   +-------------------+   +-------------------+
        |                         |                         |
        v                         v                         v
+---------------------------------------------------------------+
|                     Transaction Ledger (Append‑Only)         |
+---------------------------------------------------------------+
        |                         |                         |
        v                         v                         v
+-------------------+   +-------------------+   +-------------------+
|   DB (SQL)       |   |   Cache (Redis)  |   |   Search (ES)    |
+-------------------+   +-------------------+   +-------------------+

• API Gateway handles routing, TLS termination, and basic throttling.
• Auth Service provides JWT tokens and MFA checks.
• Wallet Service implements the core ledger logic, reading and writing to the transaction log.
• Payment Service integrates with external processors (card networks, ACH). It is deliberately isolated because third‑party latency can be high.
• Fraud Service consumes a stream of transactions, flags anomalies, and can trigger a hold on a wallet.
• Cache stores recent balances for fast reads; the source of truth remains the append‑only ledger.
• Search enables flexible queries for statements and compliance reports.

7. Deep Dive: Consistency & Double‑Entry Ledger

A digital wallet must never allow an overdraft. The classic solution is a double‑entry ledger where each transaction writes two records: a debit and a credit. The write operation is wrapped in a database transaction (or a distributed transaction if you shard). After the commit, the cache is refreshed asynchronously.

Why not just update a balance column?

• Direct updates are prone to race conditions under high concurrency.
• Auditing is harder because you lose the immutable history.
• Reconciliation with external processors becomes messy.

Trade‑off: Using a strict ACID transaction can limit throughput. To mitigate, you can:

• Partition wallets by user ID and keep each partition on a single node (sharding).
• Batch small deposits into a “pending” table that is later consolidated.
• Employ optimistic concurrency with version numbers for low‑conflict workloads.

8. Hard Parts Interviewers Probe

When you answer, keep the explanation concrete: name the component, describe the mechanism, and note the trade‑off.

9. Sample Answer (45‑90 seconds)

"The wallet consists of three main services: an API gateway, a wallet service that owns an immutable transaction ledger, and a payment service that talks to external processors. When a user sends money, the wallet service creates a double‑entry transaction inside a single DB transaction, updates a Redis cache for the balance, and publishes the event to a fraud detector. The ledger is the source of truth, so even if the cache goes down we can recompute balances. Security is handled by tokenizing card data and enforcing MFA at the gateway. We shard wallets by user hash to scale writes, and we use a saga pattern for withdrawals to guarantee idempotency."

Practicing this answer aloud with Call Assistant can help you keep the flow natural and ensure you hit each key point within the time limit.

10. Trade‑offs Summary

• Strong consistency vs. latency – Strong consistency for balances is essential; you can relax it for reporting.
• Single‑node ACID vs. sharding – Sharding improves throughput but adds complexity in cross‑shard transfers.
• In‑memory cache vs. durability – Cache speeds reads but must be rebuilt from the ledger on failure.
• External payment integration – Isolate the payment service to prevent third‑party latency from affecting the core wallet.
• Regulatory compliance – Adding a dedicated compliance microservice adds overhead but simplifies auditability.

How to practice this

1. Sketch the diagram on paper – Start with the high‑level boxes, then add the data flow for a send‑money operation.
2. Record yourself answering – Use Call Assistant to capture the answer, then replay it to trim any filler.
3. Iterate on follow‑ups – Have a friend ask you the hard‑part questions listed above; refine each response to stay under 30 seconds.

---

FAQ

• Q: Do I need to implement real‑time push notifications? A: Not for the core design. Mentioning a notification service shows awareness, but you can keep it optional unless the interviewer explicitly asks.
• Q: How much data does the transaction ledger store? A: It stores one immutable record per operation. You can discuss archiving older entries to cold storage to control cost.
• Q: Should I use SQL or NoSQL for the ledger? A: SQL gives strong ACID guarantees which simplify double‑entry bookkeeping. NoSQL can be layered on top for read‑heavy workloads, but the primary source of truth should stay relational.
• Q: What is the role of a blockchain in a digital wallet? A: Only if the product explicitly supports cryptocurrencies. For a typical fiat‑wallet, a traditional ledger is sufficient and simpler to audit.