0
0
LLDsystem_design~12 mins

Transaction history in LLD - Architecture Diagram

Choose your learning style9 modes available
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
UserLoad Balancer
Load BalancerAPI Gateway
API GatewayTransaction Service
Transaction ServiceCache
CacheTransaction Service
Transaction ServiceDatabase
DatabaseTransaction Service
Transaction ServiceCache
Transaction ServiceAPI Gateway
API GatewayLoad Balancer
Load BalancerUser
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
Test your understanding
Which component handles distributing user requests evenly?
ALoad Balancer
BAPI Gateway
CTransaction Service
DCache
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.