Problem statement 4: How can new technologies in digital wallets enable new and trustworthy user experiences?
With the advancement of technology, underserved regions or areas have trouble keeping up with the latest trends such as the lack of a stable internet connection. For financial inclusivity, TikiWallet enables transactions between users with no internet connections at all.
- The general public
- People with no access to a stable internet or mobile data connection on the go
TikiWallet partitions your wallet into 2 wallets - online and offline. In addition to your typical online transactions between users, users are able to send and receive transactions offline by being in contact with the receiver.
Client:
- Flutter
Backend:
- Express/ NodeJS hosted on Render
- PostgreSQL hosted on Google CloudSQL
- Prisma ORM
APIs Used:
- Stripe
- Twilio
Adopted a client-server monolithic architecture
Considerations:
- Small prototype project
- Fast development
Aim:
- To reduce fraud and phishing using 2FA method through OTP SMS verification
- Encrypted access to restrict access to the app by sessions through JWT
Authentication and session management is carried out using JSON Web Tokens.
Register:
- Users are to create an account with phone number, username and password
- They will then be sent an OTP through SMS to be verified with a 6 digit PIN code.
Login:
- Users login with phone number and password
Session management:
- JWT is set to expire after 6hours to ensure user authorization
- Limits access to in-app routes to signed in users
- Prevents security threats like Cross-Site Request Forgery and Cross-site Scripting
Aim:
- Utilize Stripe API to add funds from the user's bank to the wallet
- Utilize Stripe API to retract funds from the user's wallet to the bank
Aim:
- Transfer of funds between users over the internet
Online transfer:
- Calls the REST API from the backend server to transfer funds to the target user
- Authorization bearer middleware using JWT required to identify the requestor before sending a request
Aim:
- Transfer of funds between users without internet access
- Physical contact between users to ensure authentication and security
- Utilize WiFi-Direct technology to enable secure transfers offline
WiFi-Direct:
- Uses device and service discovery protocols
- Allows devices to search and discover nearby WiFi-enabled devices without the need of WiFi
- Requires devices to be WiFi-capable as it creates a wireless network between devices without an existing router.
Security and identity:
- Sender inputs the receiving phone number and receiver inputs the sending phone number to verify the identity of the transaction
- Handshake between the 2 devices to exchange and verify contact info before executing the transaction of funds
Phase 1οΈβ£: Assessment and Planning
- Define Objectives and Metrics
- What level of traffic can your app handle? What is the acceptable downtime?
- Understand Current State
- Assess your current infrastructure, technology stack, and application architecture. Identify bottlenecks and potential points of failure.
- User and Traffic Analysis
- Analyze user patterns, peak usage times, and geographic distribution. Understand your user base and how it may grow over time.
- Cost Analysis
- Estimate the budget required for implementing scalability and availability improvements. Consider cloud services, additional hardware, and software costs.
Phase 2οΈβ£: Architecture and Design
- Microservices Architecture
- Auth Service
- Transactions Service
- Accounts DB NoSQL, Transactions DB PostgreSQL
- Containerization and Orchestration
- Kubernetes
- Load Balancing
- Distribute incoming traffic across multiple servers to ensure high availability and even load distribution.
- Database Scaling
- Partition data into 2 databases for each service: PostgreSQL for transactions and MongoDB for authentication/accounts.
- Database sharding based on geographical locations of users hosted on separate servers.
- Autoscaling with AWS to automatically adjust number of database instances
- Caching Strategies
- Redis to reduce database load and improve response times for information frequently accessed. Like user account balance and transaction history.
- Store API request and response data to allow rate limiting and throttling strategies.
Phase 3οΈβ£: Infrastructure and Deployment
- Cloud Adoption
- Deploy onto AWS EKS
- Auto-scaling
- Configure auto-scaling policies to automatically adjust resources based on traffic and demand. Utilize serverless computing where possible.
- Data Replication and Backup
- Implement data replication across multiple regions for disaster recovery and backup.
Phase 4οΈβ£: Monitoring and Optimization
- Real-time Monitoring
- AWS cloudwatch to track the health and performance of your application and infrastructure. Configure alarms to trigger notifications when CPU utilization, memory usage, network traffic and storage thresholds exceed. Automatically adjust number of instances based on predefined scaling policies based on cloudwatch triggers.
- Performance Testing
- Regularly conduct load testing to identify performance bottlenecks
- Disaster Recovery Plan
- Data Replication for databases
- Automate cluster provisioning with IaC or AWS Cloudformation to quickly recreate the cluster.
- Third party disaster recovery services or AWS Disaster Recovery Service
Phase 5οΈβ£: Scaling and Growth
- Scalability Testing
- Conduct scalability tests to ensure increased loads can be handled especially during peak times.
- User Feedback
- Continuously gather user feedback and adjust scalability and availability strategies based on user needs and expectations.
- Global Expansion
- Expand the app to new geographic regions to demonstrate financial inclusion. Main purpose of our wallet is to allow transactions even without WiFi access which are more applicable to regions with lesser developed technology and reach.
A brief overview of the scalability and availability plan
- Benjamin Toh @bentohset
- Muhammad Jabir @muhdjabir
- Ryan Ong @ryanongwx
- Ryan Lim @Seibell
- Wang Yu Teng @WangYuTengg

