System requirements

Functional Requirements:

The ATM system allows bank customers to conduct financial transactions independently.

• User Authentication:
  • User can authenticate using a bank card and PIN.
  • Optionally, user can authenticate using biometric data (e.g., fingerprint, facial recognition).
• Account Management:
  • User can view account balances.
  • User can view transaction history.
  • User can change their PIN.
• Transaction Handling:
  • User can withdraw cash with daily and per-transaction limits.
  • User can deposit cash into their account.
  • User can transfer funds between their own accounts or to other users' accounts.
  • User can pay bills (e.g., utilities, credit cards).
  • User can top up mobile phone balance.
• Admin Functions:
  • Bank personnel can replenish the ATM with cash.
  • Bank personnel can perform diagnostics and monitor the ATM's health.
  • The system logs all transactions and administrative actions for audit purposes.

Non-Functional Requirements:

• Performance:
  • Each transaction should be completed within 5 seconds under normal conditions.
  • The system should support up to 500 concurrent users at peak times.
• Scalability:
  • The system must be scalable to support up to 200 ATMs within the city.
  • The system should accommodate increases in transaction volumes per ATM without performance degradation.
• Reliability:
  • The system must have 99.99% uptime.
  • Backup systems must ensure data integrity and availability (e.g., RAID storage, database replication).
• Security:
  • The system must comply with PCI-DSS standards for secure card transactions.
  • Regular security audits and vulnerability tests must be conducted.

Capacity Estimation

For the ATM system designed for a city with a population of about 500,000:

• User Base:
  • Estimate that 10% of the population (50,000 users) will regularly use ATMs.
• Transaction Frequency:
  • Each user interacts with an ATM approximately twice a week.
• Daily Transactions:
  • During peak usage, assume each ATM handles around 300 transactions per day.
• Total ATM Deployment:
  • Design for a minimum of 100 ATMs to effectively manage user demand and minimize wait times.

Data Storage:

• Assume an average transaction size of 1 KB.
• Each ATM handles 300 transactions/day:
  • 300 transactions * 1 KB = 300 KB/day/ATM.
  • For 100 ATMs: 300 KB * 100 = 30 MB/day.
• Yearly Storage Requirement:
  • 30 MB/day * 365 days = 10.95 GB/year.
• Peak Load:
  • Estimate 20% of users (10,000) might use the ATMs simultaneously during peak hours.
  • Each ATM should support up to 500 concurrent transactions across the network during these times.

API Design

User Authentication

Account Balance Inquiry

Cash Withdrawal

Fund Transfer

Admin ATM Status Check

Database Design

High-level design

ATM Interface:

• The physical interface that users interact with, including the card reader, keypad, display, and cash dispenser.
• Communicates with the backend services to process user requests.

Authentication Service:

• Handles user authentication using card and PIN or biometric data.
• Issues tokens upon successful authentication, which are used for subsequent transactions.

Transaction Processing Service:

• Processes financial transactions such as withdrawals, deposits, and transfers.
• Interacts with the account service to update balances and ensure transactional integrity.

Account Service:

• Manages user accounts, including balance inquiries, transaction history, and fund transfers.
• Ensures data consistency and handles concurrency control.

ATM Management Service:

• Monitors and manages ATM status, including cash levels, hardware health, and service availability.
• Alerts bank personnel for maintenance and cash replenishment.

Security and Compliance Service:

• Ensures all transactions are secure, encrypted, and compliant with regulations.
• Monitors for fraud and unusual activity, and triggers alerts as needed.

Notification Service:

• Sends transaction receipts to users via email or SMS.
• Notifies users of important account activities, such as low balance alerts.

Database:

• Stores all user, account, transaction, and ATM data.
• Ensures data is replicated and backed up to prevent loss and maintain integrity.

Admin Interface:

• Used by bank staff to manage ATMs, review transaction logs, and monitor system health.
• Provides detailed reports and analytics.

Request flows

1. Cash Withdrawal Flow

• User inserts card and enters PIN.
• Authentication Service validates credentials and returns a token.
• User requests cash withdrawal.
• Transaction Processing Service checks balance via Account Service.
• If funds are sufficient, ATM dispenses cash.
• Transaction is logged in the Database and balance updated.
• Notification Service sends a receipt to the user.

2. Balance Inquiry Flow

• User selects "Check Balance."
• Transaction Processing Service requests balance from Account Service.
• Account Service retrieves balance from the Database.
• ATM displays the balance to the user.

3. Fund Transfer Flow

• User selects "Transfer Funds" and enters details.
• Transaction Processing Service checks balance via Account Service.
• If funds are sufficient, balances of both accounts are updated.
• Transaction is logged in the Database.
• Notification Service sends a confirmation to the user.

Detailed component design

Transaction Processing Service

• Horizontal Scaling: The Transaction Processing Service is designed to scale horizontally by adding more instances as transaction load increases. A load balancer distributes incoming requests evenly across these instances to prevent any single instance from becoming a bottleneck.
• Sharding: Account data can be sharded based on user ID or account number to distribute the load across multiple database nodes, ensuring that no single database node becomes a point of failure.

Authentication Service

• Stateless Design: The Authentication Service is stateless, meaning each request is independent of others. This design allows the service to scale horizontally, with additional instances added as needed without concerns about session management.
• Token-based Authentication: After the initial authentication, a token is issued that can be used for subsequent transactions, reducing the load on the service by eliminating the need for repeated authentication checks.

Notification Service

• Asynchronous Processing: Notifications are processed asynchronously, allowing the core transaction to complete without waiting for notification delivery.
• Distributed Queue System: A distributed message queue (e.g., Kafka) ensures that notifications are processed reliably and can scale horizontally to handle increasing loads.
• Batch Processing: Notifications can be batched to reduce the number of calls to external services (e.g., SMS or email providers), improving throughput and reducing costs.

Trade offs/Tech choices

In-Memory Caching vs. Direct Database Access

• Choice: In-memory caching (e.g., Redis) was used for frequently accessed data, such as account balances.
• Reasoning: Caching reduces the load on the database by serving repeated queries from memory, which is much faster than disk-based database access. This leads to improved response times, especially during peak load.
• Trade-off: Caching introduces the risk of serving stale data if the cache is not properly synchronized with the database. However, with careful cache invalidation strategies, this risk can be minimized, making caching a valuable performance optimization tool.

Token-Based Authentication vs. Session-Based Authentication

• Choice: A token-based authentication system was implemented instead of a session-based system.
• Reasoning: Token-based authentication is stateless, making it easier to scale the Authentication Service horizontally. It also reduces the need for session management, which can be complex and resource-intensive.
• Trade-off: Tokens need to be securely stored and transmitted, and there is a risk of token theft if not handled properly. However, the stateless nature and ease of scaling make token-based authentication the better choice for this system

Failure scenarios/bottlenecks

1. Service Overload

During peak times, critical services like the Transaction Processing Service might receive more requests than they can handle. This could slow down the entire system or even cause it to fail.

To prevent this, the system should use auto-scaling to add more service instances as the load increases. Implementing rate limiting can also help by controlling the number of requests processed at any given time, preventing overload.

2. Single Points of Failure

If any critical component, like the Authentication Service or the primary database, fails, it could bring down the entire ATM system. This is a significant risk in any high-availability system.

To mitigate this, the system should be designed with redundancy in mind, ensuring that there are backup instances of critical services and databases that can take over automatically if the primary instance fails.

3. Security Breaches

Security is always a concern, especially in a system handling financial transactions. A breach, such as unauthorized access or a DDoS attack, could compromise the system’s integrity and availability.

To defend against this, the system should deploy intrusion detection systems (IDS) to monitor for suspicious activities and take immediate action if a threat is detected.

Future improvements

1. Enhanced Biometric Authentication: Expand the biometric authentication options to include newer technologies like iris scanning or voice recognition. This would provide users with more secure and convenient ways to access their accounts, reducing reliance on PINs, which can be easily compromised.

2. Integration with Digital Wallets: Enable the ATM system to support digital wallet transactions, allowing users to withdraw cash or complete transactions using mobile payment apps like Apple Pay or Google Wallet. This would align with the growing trend of mobile-first banking and enhance user convenience.