Read/Write Database Architecture with Read Replicas

Modern applications often process significantly more reads than writes.

Consider an e-commerce platform with:

• 1 million users
• A large number of product and catalog reads
• Fewer writes such as orders, profile updates, and inventory changes

If every request goes to the same database:

Application → Single Database

the primary database can quickly become a bottleneck.

For example, the application workload might consist of:

90% reads and only 10% writes.

Instead of continuously scaling one database vertically, we can separate read traffic from write traffic.

This is where read replicas become useful. They allow read-heavy workloads to be distributed across multiple database instances.

How Database Replication Works

When the application performs a write:

UPDATE customer SET name = ‘John’ WHERE id = 100;

the write is committed to the primary/writer database.

The database replication mechanism then propagates those changes to the read replicas.

Replication is commonly asynchronous, which introduces an important trade-off:

Replication lag.

For example:

10:00:00.000 → User updates address
10:00:00.010 → Primary commits the update
10:00:00.100 → Replica receives the update

In this example, there is approximately 90 ms replication lag.

During that short period, the primary contains the latest value while the replica may still contain the old value.

The Read-After-Write Consistency Problem

Suppose a user updates their address and immediately refreshes their profile.

If that subsequent GET request is routed to a read replica before replication has completed, the application may return the old address.

This creates a stale-read problem.

One common solution is:

For a short period after a write, route that user’s consistency-sensitive reads back to the writer database.

This pattern is commonly called:

Sticky Reads
or
Read-Your-Own-Writes Consistency.

What Data Should Go to Read Replicas?

Not every SELECT operation has the same consistency requirement.

Read replicas are excellent candidates for:

• Product catalog
• Search data
• Historical orders
• Reports
• Dashboards
• Analytics queries
• Reference data

These workloads generally tolerate small replication delays while benefiting significantly from read scalability.

However, be more careful with data such as:

• Payment status
• Inventory immediately after purchase
• Account balance
• Transaction status
• Security-sensitive state

For these consistency-sensitive operations, the application may intentionally read from the writer database.

How Does Read/Write Routing Work?

At enterprise scale, read/write routing can be implemented using several approaches:

• Application data-source routing
• Database proxy
• Database endpoints
• Service-level separation

For a Spring Boot application, a routing layer can determine whether a request should go to:

Writer DataSource

or

Reader DataSource

Normal read traffic can use the reader endpoint.

Writes and consistency-sensitive reads can use the writer endpoint.

Using Redis for Read-After-Write Routing

A practical implementation can use Redis to store a short-lived writer-stickiness marker after a successful transaction.

The flow can look like this:

1. Transaction request arrives

The Spring Boot service receives a write request.

2. Write goes to the writer database

The application performs the transaction against the primary database.

3. After successful commit, create a marker

For example:

recent-write:user-100 = true
TTL = few seconds

The marker can be stored in Redis.

4. Subsequent sensitive reads check the marker

If the marker exists:

Read → Writer DB

Otherwise:

Read → Reader Endpoint

5. Marker expires

After the sticky period expires, normal traffic returns to read replicas.

6. Monitor replication lag

If replication lag becomes abnormal, the application or operational layer can temporarily route critical reads back to the writer.

Important: Redis is one implementation option for maintaining this temporary routing state. It is not inherently required for every read-replica architecture.

AWS Aurora Read/Write Architecture

AWS Aurora provides a useful abstraction for this architecture through database endpoints.

The application typically works with two important endpoint concepts.

Writer Endpoint

Used for:

• INSERT
• UPDATE
• DELETE
• Transactional reads when necessary

Reader Endpoint

Used for:

• Read-only queries
• Distributing read connections across Aurora Replicas

This means your application doesn’t necessarily need to know the address of every individual replica.

What Happens When the Aurora Writer Fails?

One major benefit of managed database platforms such as Aurora is failover abstraction.

If the current writer fails, Aurora can promote another suitable instance.

Applications continue connecting through the writer/cluster endpoint instead of having to know which physical database instance currently acts as the writer.

This reduces application-side failover complexity.

Multi-AZ vs Read Replica

This is also a very common system-design interview question.

Multi-AZ	Read Replica
Primarily high availability	Primarily read scalability
Protects against infrastructure/database failure	Reduces read load on primary
Supports failover	Handles read queries
Availability-focused	Performance/scalability-focused

A simple way to remember it:

Multi-AZ → Availability

Read Replica → Scalability

Further Optimization Using Distributed Caching

Read replicas reduce load on the writer.

But there is another optimization layer we can introduce:

Distributed caching.

For example, using Redis:

This reduces repeated database queries for frequently accessed data.

Do Read Replicas Solve Write Scaling?

No.

Read replicas primarily solve:

Read scalability.

If the problem is high write traffic, other approaches may be required, including:

• Partitioning
• Sharding
• Batching
• Asynchronous processing
• Different database technologies

These solve a different class of scaling problem and should not be confused with read replicas.

Final Production Architecture

Redis can help maintain short-lived routing state.

RDS Proxy can help with connection management and pooling.

Aurora handles the writer/replica topology and replication.

And the Spring Boot routing layer makes the consistency decision for each request.

Key Takeaways

The main concepts to remember are:

1. Writer handles writes.
2. Read replicas scale reads.
3. Replication may be asynchronous.
4. Replication lag can produce stale reads.
5. Consistency-sensitive read-after-write traffic may need to use the writer.
6. Reader endpoints simplify access to replicas.
7. Redis can support temporary writer-stickiness or distributed caching.
8. RDS Proxy can help manage database connections.
9. Read replicas solve read scaling, not write scaling.

Frequently Asked Interview Questions

1. Why would you introduce read replicas?

To horizontally scale read-heavy workloads and reduce load on the primary database.

2. Can I send every SELECT query to a replica?

No.

Consistency-sensitive reads may need to hit the writer because replication lag can return stale data.

3. What happens if a read replica fails?

That replica should stop receiving read traffic.

With Aurora, the reader endpoint abstracts the replicas so applications don’t have to manage every replica directly.

4. What happens if the writer fails?

Aurora can promote another suitable instance, while the writer/cluster endpoint continues pointing applications toward the current primary.

5. Does a read replica solve high write traffic?

No.

Read replicas primarily address read scalability, not write scalability.

6. Multi-AZ vs Read Replica?

A simple interview answer:

Multi-AZ → High Availability

Read Replica → Read Scalability

7. Would each Aurora replica require a separate JDBC URL?

Normally, applications can work with the cluster’s writer and reader endpoints rather than maintaining a JDBC URL for every replica.

Conceptually:

jdbc:postgresql://<writer-endpoint>/orders
jdbc:postgresql://<reader-endpoint>/orders

8. What database metrics should we monitor?

Important metrics include:

• Replica lag
• Database CPU
• Connections
• Read/write IOPS
• Query latency
• Disk/storage
• Deadlocks
• Slow queries
• Failovers
• Connection-pool saturation