Read Replica
matureSummary
Distribute read queries across one or more synchronous or asynchronous replicas of a primary database node, reducing read load on the primary.
Problem
A single database primary cannot serve read throughput beyond its I/O and CPU limits. Read replicas expand read capacity without requiring schema changes or application rewrites.
Description
A read replica is a copy of the primary database that receives changes via replication (streaming replication in PostgreSQL, binlog replication in MySQL). Read queries are routed to replicas, while write queries go to the primary. Replication is typically asynchronous, introducing a lag window during which replicas may serve stale data.
Tradeoffs
Strong horizontal read scaling
No improvement: single primary for all writes
Eventual consistency: replica lag introduces stale read windows
Moderate: replication monitoring, failover runbooks required
Linear cost increase per replica
When to use
Read-to-write ratio exceeds 70:30
Replicas only help if most traffic is reads
Primary is CPU or I/O bound on read queries
If writes are the bottleneck, replicas do not help
Application can tolerate slightly stale reads (eventual consistency)
Asynchronous replication means replicas may lag behind primary
Workload is OLTP with many concurrent simple read queries
Complex OLAP queries may overwhelm replicas the same as the primary
When not to use
All reads require seeing the latest write (read-your-own-writes consistency)
Replication lag breaks this guarantee unless routing is careful
Write throughput is the bottleneck
Replicas do not increase write capacity: primary handles all writes
Connection count is the bottleneck, not query throughput
PgBouncer or connection pooling is the correct tool
Operational Requirements
Monitor replication lag continuously
Lag spikes indicate replica falling behind; must alert on sustained lag
Implement read routing logic in application or proxy
Application must route reads to replicas and writes to primary
Test failover procedure for replica promotion
Replicas are promotion candidates if primary fails
Characteristics
Technologies
Canonical
Alternatives
Relationships
Evolves from
Evolves to
Complements
Conflicts with
Basis
Well-established pattern with decades of production use
Related Architecture Knowledge
Outbound: this entity affects
The read replica pattern is structurally vulnerable to replication lag cascade because its value proposition: serving reads from replicas: depends on replica data being sufficiently current. Any condition that delays WAL replay degrades or invalidates the replica's usefulness.
Tradeoffs
- ·Synchronous commit eliminates lag but halves write throughput
- ·Lag-aware routing adds application complexity and requires replica health metadata
- ·Aggressive lag thresholds shift all traffic to primary under load, negating scale benefits
Inbound: affects this entity
PostgreSQL's built-in streaming replication provides the replication substrate that makes the read replica pattern operational. Physical and logical replication are both supported, enabling read scaling without data modification.
Tradeoffs
- ·Synchronous replication eliminates lag but doubles write latency
- ·Asynchronous replication allows data loss equal to replication lag on primary failure
- ·Each replica consumes WAL sender processes on the primary
Used In Architecture Scenarios
Financial Ledger
An append-only audit log architecture for capturing system actions: user operations, data access events, configuration changes, and financial operations: with cryptographic integrity chaining, immutable storage, and dual-path query serving. PostgreSQL stores the authoritative append-only event log in time-partitioned tables; ClickHouse serves historical aggregate queries and retention analytics; Kafka streams audit events in real time to SIEM integrations and security dashboards; Redis caches hot audit query results for compliance-facing read paths. No record is ever updated or deleted: only inserts are permitted. Each record includes a hash of the previous record, forming a tamper-evident chain verifiable without external tooling.
Read-Heavy Application
A CMS for publishing and serving structured content: articles, documentation, product pages, and localized variants: where read APIs serve 50–100x more traffic than editorial write APIs. PostgreSQL stores the content graph (articles, authors, categories, taxonomy) and workflow state (draft, in-review, scheduled, published). Redis caches published content objects for read APIs. Elasticsearch powers full-text content search with faceting and relevance ranking. Cache invalidation on publish must be fast and complete; N+1 query patterns on content relationship traversal are the dominant database performance risk during reads.
Multi-Tenant SaaS
A multi-tenant developer tooling platform providing CI/CD pipeline execution, log aggregation, code analysis, and dependency scanning across isolated tenant organizations. Tenant isolation is the primary correctness constraint: a security boundary violation between tenants is a critical incident, not a performance event. PostgreSQL row-level security enforces data isolation; Redis manages job queues and distributed locks; Elasticsearch indexes pipeline log output for search; Kafka delivers webhook events to tenant-registered endpoints; MinIO stores pipeline artifacts. Resource quota enforcement prevents any single tenant's burst from affecting others.
Financial Ledger
An electronic health record (EHR) architecture built around strict auditability, HIPAA compliance, and append-only correctness. Clinical records are mutable by design (amendments, addenda) but corrections must be explicitly attributed, not silently overwritten. Event sourcing provides a reconstructable audit log; PostgreSQL row-level security enforces patient-level access control at the database layer; Kafka streams HL7 FHIR events to downstream clinical systems. The architecture must support breach detection, access auditing, and state reconstruction at any historical point: not just current state retrieval.
Read-Heavy Application
A standard SaaS API architecture optimized for read-dominant workloads. PostgreSQL serves as the primary data store, Redis provides a caching layer for hot data, connection pooling bounds database concurrency, and read replicas scale read throughput without scaling write capacity.
Event-Driven System
A social activity feed architecture where user actions (posts, likes, comments, follows) fan out asynchronously to follower timelines. Redis stores hot feed data as pre-materialized lists per user, enabling O(1) timeline reads for the 99th percentile of users. Kafka carries fan-out work to async workers that write to follower Redis keys. PostgreSQL is the durable store for the social graph, posts, and user content. The system uses a hybrid fan-out model: fan-out-on-write for users with fewer than ~10,000 followers (low fan-out cost), fan-out-on-read for high-follower celebrity accounts where pre-materialized fan-out would saturate workers and Redis write bandwidth.