Getting Ready: Digital Wallet

Digital wallets are the backbone of modern financial technology. PayPal processes over $1.36 trillion in payment volume annually. Venmo handles$245 billion in peer-to-peer transfers. Apple Pay, Google Pay, Paytm, Cash App — every major tech company either builds or integrates a wallet system. The reason is simple: holding and moving money digitally is one of the most common software operations in the world.

What makes a digital wallet fascinating from a design perspective is the zero tolerance for inconsistency. When you move $100 from Alice to Bob, exactly$100 must leave Alice's balance and exactly $100 must appear in Bob's. If either side fails, neither should happen. This is the principle of atomicity — and implementing it in object-oriented code (before databases are involved) is a real engineering challenge.

Beyond atomicity, wallets must handle idempotency (retrying a network-failed transfer shouldn't charge the sender twice), concurrent access (two threads withdrawing from the same wallet mustn't overdraft it), and extensibility (adding new operation types like scheduled payments or refunds shouldn't require rewriting existing code). These constraints make the Digital Wallet a rich, interview-worthy medium-difficulty design problem that builds directly on the Command and Observer patterns you've seen in earlier problems.

By the end of this design problem, you will be able to:

• Model financial transactions as Command objects — each deposit, withdrawal, and transfer becomes an encapsulated operation that can be executed, logged, and potentially reversed
• Apply the Observer pattern for real-time transaction notifications to wallet holders
• Design an idempotency mechanism that prevents duplicate processing of retried requests
• Create a class diagram tracing every class back to a specific requirement
• Build a sequence diagram for the P2P money transfer flow showing idempotency checks, balance validation, command execution, and notification dispatch
• Implement ACID-like transaction guarantees — atomic transfers that either fully complete or fully rollback
• Handle concurrent wallet access with lock ordering to prevent deadlocks and double-spending
• Write targeted tests for financial edge cases: insufficient funds, self-transfer, concurrent operations, and idempotent retries

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition and Association (Fundamentals S4). You'll model wallets composed within users and transactions composed within wallets.
• Command Pattern — encapsulating operations as objects (Fundamentals S12). We'll use this for every transaction type. If you completed the Task Manager (DP7), you've already applied this pattern for undo/redo.
• Observer Pattern — notifying interested parties when events occur (Fundamentals S12). The Pub-Sub system (DP13) and Logging Framework (DP5) both used this.
• UML Class & Sequence Diagrams — how to read and draw them (Fundamentals S5).
• Basic Concurrency Concepts — threads, locks, and race conditions (Fundamentals S14). The concurrency extension will build on these.

We will design:

• Core wallet operations — create wallet, deposit, withdraw, check balance
• Peer-to-peer (P2P) money transfers between wallets
• Transaction logging with complete history per wallet
• Command-based transaction architecture for extensibility
• Idempotency key mechanism to prevent duplicate processing
• Observer-based notifications on transaction completion
• Thread-safe wallet operations with atomic transfers
• Payment method abstraction (bank account, credit card)

We will NOT design:

• Database persistence layer, REST APIs, or microservice architecture — this is an object-oriented design exercise, not a system design problem
• KYC (Know Your Customer) or identity verification workflows
• Fraud detection or machine learning-based risk scoring
• Currency conversion or multi-currency support
• Distributed transactions across multiple services
• Payment gateway integration (Stripe, Razorpay, etc.)

Our focus is the in-memory object model — the class structure, relationships, and behavioral logic that would sit behind any persistence or API layer.