System requirements

Functional:

Functional requirements describe what the system should do. Here are some suggested requirements for our system:

1. Transaction Scheduling: Users should be able to schedule different types of transactions including one-time, recurring, and conditional payments.
2. User Management: The system should manage user accounts including authentication, authorization, and password management.
3. Notification System: Users should receive notifications regarding the status of their transactions, including successes and failures.
4. Admin Panel: For back-end management, including transaction oversight and user account management.
5. Reporting and Analytics: Generate reports for transactions, spotting trends, and tracking transaction history.
6. Security Features: Ensure data encryption, secure data storage, and secure transmission protocols.

Non-Functional:

Non-functional requirements describe how the system operates, underlining the quality attributes of the system:

1. Scalability: The system must handle a high number of transactions and users without degradation of performance.
2. Reliability: Achieve high availability with minimal downtime.
3. Usability: Interface must be user-friendly for both end-users and administrators.
4. Security: Implement robust security measures to protect against fraud and cyber threats.
5. Performance: Transactions should be processed in a timely fashion, with real-time processing capabilities as needed.
6. Maintainability: Code and systems should be designed for easy maintenance and future upgrades.

Capacity estimation

Assumptions

To estimate the system's capacity, we need to make a few assumptions about usage patterns and transaction volumes:

1. Number of Users: Estimate the number of active users who will use the system. For instance, we might start with 100,000 active users.
2. Transaction Frequency: Estimate how often these users will schedule transactions. Let’s assume each user schedules 3 transactions monthly.
3. Peak Load: Identify peak hours during which transaction volume might double.

Calculation

Based on the above assumptions:

1. Monthly transactions = 100,000 users × 3 transactions/user = 300,000 transactions per month.
2. If we estimate peak hours to see 10% of daily transactions, then,
3. Daily transactions = 300,000 transactions / 30 days ≈ 10,000 transactions.
4. Peak hour transactions = 10% of daily transactions = 1,000 transactions in the peak hour.

System Requirements

To handle these transactions smoothly:

1. Database Operations: Capable of handling at least 50 writes per second during peak times (as transactions might involve multiple database interactions).
2. Storage: Sufficient storage for user data, transaction logs, and backups. Assuming small metadata per transaction, storage should scale with user base and retention policy.
3. Network Bandwidth: Ensure adequate bandwidth to support data transmission needs during peak loads.

API design

The APIs will be structured to facilitate core functionalities such as user management, transaction scheduling, and system administration.

User Authentication API

Authenticate users and provide tokens for session management.

 Schedule Transaction API

 Schedule a new transaction for execution.

Check Transaction Status API

Retrieve the status of a scheduled transaction.

Admin API to Oversee Transactions

View all transactions within the system for monitoring and management purposes.

Database design

We will use a relational database model for our system. Here's a proposed Entity-Relationship (ER) diagram and corresponding descriptions:

Entities:

1. User: Stores information about system users.
2. Transaction: Contains all details about transactions scheduled by users.
3. Transaction_Log: Captures logs of all transaction activities for auditing and troubleshooting.

Attributes:

1. User: user_id, username, email, hashed_password, created_at
2. Transaction: transaction_id, user_id, amount, currency, transaction_type, status, scheduled_date, executed_date
3. Transaction_Log: log_id, transaction_id, status, timestamp, details

Relationships:

1. A User can have multiple Transactions (One-to-Many).
2. A Transaction generates multiple Transaction_Logs (One-to-Many).

High-level design

The system architecture will be based on a microservices model to ensure scalability, maintainability, and robust fault isolation. Here's a breakdown of the primary components:

Key Components:

1. User Service: Manages user registration, authentication, and profile management.
2. Transaction Service: Handles all aspects of transaction scheduling, execution, and status updates.
3. Notification Service: Sends out alerts and notifications to users regarding transaction statuses and other important events.
4. Admin Service: Provides administrative capabilities to manage the system, oversee transaction logs, and generate reports.
5. Database: Central storage for user data, transactions, and logs.
6. API Gateway: Entry point for all client requests, routing them to the appropriate services.
7. Load Balancer: Distributes incoming traffic and requests across servers to ensure reliable and efficient performance.

Component Interaction:

• Client requests (e.g., scheduling a transaction or checking transaction status) are sent to the API Gateway, which routes them to the appropriate service.
• The Load Balancer efficiently distributes incoming requests across multiple instances of each service to handle high loads and increase fault tolerance.
• Each service interacts with the Database to retrieve or store data, ensuring that all transaction records are consistently managed and maintained.

Request flows

We'll use a sequence diagram to represent the flow for a typical transaction scheduling request, from the client making the request through the system until the transaction is scheduled in the database.

Request Flow Description:

1. Client Submission: A user submits a transaction scheduling request via a client interface (web or mobile).
2. API Gateway: The request hits the API Gateway, which authenticates the user and forwards the request to the Load Balancer.
3. Load Balancer: Distributes the request to one of the available Transaction Service instances.
4. Transaction Service: Processes the request, checks transaction rules and parameters, and then interacts with the Database to store the transaction details.
5. Database: Records the transaction and confirms back to the Transaction Service.
6. Notification Service: Optionally, the Transaction Service might call the Notification Service to send a confirmation message to the user about the scheduled transaction.
7. Response to Client: Finally, the Transaction Service sends a response back to the client through the API Gateway, confirming that the transaction has been scheduled.

Detailed Component Design

Transaction Service

Functionality:

• Manages all aspects of transactions including creation, scheduling, and status updating.
• Validates transaction conditions and schedules based on user input.

Scalability:

• Designed as a stateless service to scale horizontally. New instances can be added to handle increased load.
• Utilizes a distributed queue (e.g., Kafka or RabbitMQ) for handling transaction execution tasks, allowing decoupling of transaction scheduling from execution.

Algorithms/Data Structures:

• Uses a priority queue based on scheduled time for managing when transactions are executed, ensuring that transactions are processed in the correct order.
• Hash tables are used to store transaction details for quick access and status updates.

Notification Service

Functionality:

• Sends notifications to users regarding transaction statuses (e.g., scheduled, completed, failed).
• Handles both email and SMS notifications depending on user preferences.

Scalability:

• The service can scale independently based on notification volume, separate from transaction processing.
• Uses a publish-subscribe model with a message broker to handle notification requests, which allows it to efficiently distribute notification tasks across multiple workers.

Algorithms/Data Structures:

• Implements event-driven architecture using message queues to trigger notifications based on transaction events.
• Utilizes template engines for generating notification content dynamically, optimizing the process of message creation.

Trade offs/Tech choices

1. Choice of Microservices Architecture

• Pros:
• Scalability: Allows each component of the system to scale independently based on demand.
• Maintainability: Changes in one service do not require redeploying the entire application, reducing downtime and risk.
• Cons:
• Complexity: More complex to set up and manage compared to a monolithic architecture. Requires sophisticated service discovery and management strategies.
• Data consistency: Ensuring data consistency across services can be challenging and often requires implementing additional patterns such as Saga.

2. Use of Relational Database

• Pros:
• ACID Transactions: Ensures that all transaction data is consistently stored, which is critical for financial applications.
• Well-understood Technology: Relational databases are a mature technology with extensive support and community knowledge.
• Cons:
• Scalability Limitations: Horizontal scaling is more complex and typically less efficient than with NoSQL databases.

3. Employment of a Distributed Message Queue (e.g., Kafka)

• Pros:
• Decoupling: Components such as the Transaction Service and Notification Service are decoupled, enhancing fault tolerance and scalability.
• Replayability: Enables replaying of messages for scenarios like system failures or for new service integration.
• Cons:
• Operational Overhead: Requires managing another complex component within the infrastructure.

4. Event-Driven Architecture for Notifications

• Pros:
• Responsiveness: Allows the system to react in real-time to transaction events, sending notifications immediately.
• Scalability: Easily scales to handle large volumes of notifications by adding more subscribers.
• Cons:
• Event Consistency: Requires careful handling to ensure that all events are processed in order and none are missed or duplicated.

Technology Stack Suggestion

• Frontend: React or Angular for dynamic web interfaces.
• Backend: Node.js or Java/Spring Boot for creating robust microservices.
• Database: PostgreSQL for robust relational data management.
• Message Queue: Apache Kafka for handling distributed messaging.
• Load Balancer: Nginx or HAProxy to distribute incoming traffic.
• Monitoring and Logging: Prometheus and ELK Stack for monitoring services and logging system activities.

Future Improvements

To enhance the Scheduled Digital Transaction System further, consider the following upgrades:

1. Implementing Machine Learning: Use machine learning algorithms to detect fraudulent transactions and improve security measures dynamically based on transaction patterns.
2. Blockchain for Transaction Integrity: Explore using blockchain technology to ensure the integrity and non-repudiation of transactions, especially in a system involving financial records.
3. Service Mesh Implementation: Integrate a service mesh like Istio to manage service-to-service communications, providing better load balancing, service discovery, and secure service communication.
4. Advanced Analytics Capabilities: Develop advanced analytics for transaction data to provide insights into user behavior, predict trends, and enable data-driven decision-making.