0
0
HLDsystem_design~12 mins

Read replicas in HLD - Architecture Diagram

Choose your learning style9 modes available
System Overview - Read replicas

This system uses read replicas to improve database read scalability and availability. It handles many read requests by distributing them across multiple replicas, while writes go to the primary database.

Key requirements include fast read response times, data consistency with some replication delay, and fault tolerance for database failures.

Architecture Diagram
User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +-------------------+
  |                   |
  v                   v
Primary DB          Read Replica 1
  |                   |
  |                   v
  |               Read Replica 2
  |
  v
Cache
Components
User
client
Sends requests to the system
Load Balancer
load_balancer
Distributes incoming requests evenly to API Gateway instances
API Gateway
api_gateway
Routes requests to appropriate services and manages read/write separation
Primary DB
database_primary
Handles all write operations and replicates data to read replicas
Read Replica 1
database_replica
Handles read requests to reduce load on primary database
Read Replica 2
database_replica
Additional read replica for scalability and availability
Cache
cache
Stores frequently accessed data to speed up read responses
Request Flow - 9 Hops
UserLoad Balancer
Load BalancerAPI Gateway
API GatewayCache
CacheAPI Gateway
API GatewayRead Replica 1 or 2
Read Replica 1 or 2API Gateway
API GatewayUser
API GatewayPrimary DB
Primary DBRead Replica 1 and Read Replica 2
Failure Scenario
Component Fails:Primary DB
Impact:Writes fail and data cannot be updated; reads from replicas may be stale
Mitigation:Promote a read replica to primary; use replication lag monitoring to ensure data freshness
Architecture Quiz - 3 Questions
Test your understanding
Which component handles write operations in this architecture?
APrimary DB
BRead Replica 1
CCache
DLoad Balancer
Design Principle
This architecture uses read replicas to separate read and write workloads, improving read scalability and availability. Caches reduce database load further. Replication delay introduces eventual consistency, which is acceptable for many read-heavy applications.