Part 1 : Building a Digital Wallet : A Stroll through its Innards
Part 2: Digital Wallet : The Architecture
Introduction
Picture this: You’re chilling on your couch, surfing the web, and you stumble upon a shiny new gadget that you just have to have. You click on the “Buy Now” button, choose your payment method, and voila! The gadget is on its way to your doorstep. But wait, how did your money just magically teleport to the seller?
Enter Digital Wallets that makes this magic possible. It’s pretty cool, right? Now, ever wondered how this magic trick works behind the curtains? Buckle up, folks! We’re going on a fun ride to uncover the secrets of this digital magician!
Functional Requirements
So, what’s our digital wizard got up its sleeve? Here are the tricks it needs to pull off:
- Creating a Wallet: No wallet, no money. So, the first trick is to create a digital wallet for each user.
- Transferring Money: What’s a wallet without some cash in it? Our system needs to be able to transfer funds between wallets.
- Showing Account Statements: Users should be able to peek into their wallets and see their account statements whenever they want.
- Giving an Overview: The system should be able to show all account numbers in the system and their current balances.
But wait, there’s more! Our digital magician also has some special tricks for users who love a little extra:
- Offer 1: If user A sends money to user B and they end up having the same balance, both get a bonus! More money, more fun!
- Offer 2: The top 3 users with the highest number of transactions get rewarded. Everybody loves a winner, right?
- Fixed Deposits: Users can lock in an amount as a fixed deposit. If they maintain a certain balance for the next 5 transactions, they get bonus interest. Talk about money making money!
Non-Functional Requirements
Now that we know the tricks, let’s talk about what our magician needs backstage to pull them off:
- Performance: Our magician needs to be quick. No one likes to wait, especially not for money.
- Availability: The show must go on, always. Our system needs to be up and running 24/7.
- Scalability: The more, the merrier. As the audience grows, our system should be able to handle the increased load.
- Security: The magic should remain secret. Transactions need to be secure to keep the fraudsters at bay.
- Maintainability & Extensibility: Our magician needs to learn new tricks and improve old ones. The system should be easy to update and maintain.
Extended Requirements
And just when you thought we were done, here are a few more tricks:
- Double Spend: Making sure no one can spend the same money twice. That’s cheating!
- Transaction Timeout: If a trick takes too long, it’s no fun. If a transaction doesn’t finish in time, it should be cancelled.
- Fraud Detection: We need to spot the fraudsters before they can spoil the show.
Estimations:
Capacity Estimation
If we assume 30 million transactions per day, this could mean a peak of around 2 million transactions per hour if the activity is evenly distributed (which is unlikely, but it’s a useful simplification for our estimates). However, to account for peak times, we might want to design our system to handle double that amount, so around 4 million transactions per hour.
Traffic Estimation
Assuming our system needs to support 4 million transactions per hour, this translates to approximately 1,111 transactions per second. This estimation is crucial for understanding the amount of traffic the system must handle and for designing our services and databases to support this level of throughput.
Storage Estimation
For storage, we would need to consider the size of a transaction record. Let’s assume a transaction record includes:
- A unique transaction ID (let’s say 16 bytes)
- The sender’s account ID (16 bytes)
- The recipient’s account ID (16 bytes)
- The amount transferred (8 bytes)
- The date and time of the transaction (8 bytes)
This would give us a total of 64 bytes per transaction. For 30 million transactions per day, we would therefore need about 1.8 gigabytes of storage per day. Over the course of a year, this would amount to around 657 gigabytes.
Please note that these estimations are quite simplified and in a real-world scenario, you would likely need to account for additional factors such as redundancy, backups, indexing, and other metadata. Also, the storage for the user and account information would need to be considered separately.
The actual architecture would involve various layers including user interfaces (mobile apps, web apps), application servers, databases, and possibly a caching layer for performance optimization. The precise details would depend on the specifics of the use case, the technology stack, and the non-functional requirements such as response time, availability, security, and data consistency needs.
In the next part of this series, we’ll delve deeper into the nuts and bolts of the payment system, including the design of APIs, databases, and more. Stay tuned!
🔗 Connect with me on LinkedIn!
I hope you found this article helpful! If you’re interested in learning more and staying up-to-date with my latest insights and articles, don’t hesitate to connect with me on LinkedIn.
Let’s grow our networks, engage in meaningful discussions, and share our experiences in the world of software development and beyond. Looking forward to connecting with you! 😊
