Transaction history in LLD - Architecture Diagram

System Overview - Transaction history

This system records and retrieves users' transaction histories. It must handle many users making transactions simultaneously and allow quick access to past transactions.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
Transaction Service
  |
  +--> Cache
  |
  v
Database

Components

User

client

Initiates requests to view or add transaction history

Load Balancer

load_balancer

Distributes incoming user requests evenly to API Gateway instances

API Gateway

api_gateway

Handles authentication, routing, and request validation

Transaction Service

service

Processes transaction history requests and updates

Cache

cache

Stores recent transaction history for fast retrieval

Database

database

Stores all transaction history records persistently

Request Flow - 11 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Transaction Service

Transaction Service → Cache

Cache → Transaction Service

Transaction Service → Database

Database → Transaction Service

Transaction Service → Cache

Transaction Service → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:Database

Impact:New transactions cannot be saved; cache may serve stale data for reads

Mitigation:Use database replication for failover; cache serves read requests temporarily; writes queued or retried later

Architecture Quiz - 3 Questions

Which component handles distributing user requests evenly?

A Load Balancer

B API Gateway

C Transaction Service

D Cache

Design Principle

This architecture uses caching to reduce database load and improve response time. Load balancers and API gateways ensure scalability and security. Database replication and cache help maintain availability during failures.