Spring Boot Interview — Why Does My API Return Stale Data

Because even your database deserves a receipt before it serves you old data 😄

Scenario

Your team recently scaled your Spring Boot application by introducing PostgreSQL read replicas.

Architecture :

Client
  ↓
Spring Boot Service
  ↓
Primary DB (writes)
  ↓
Read Replica (reads)

To improve throughput:

• Writes → Primary

• Reads → Replica

Everything looks good in load testing.

And then customer complaints start.

A user updates their profile:

PUT /users/123
{
  "displayName": "Suraj"
}

Immediately after:

GET /users/123

Expected:

{
  “displayName”: “Suraj”
}

Actual (sometimes):

{
  “displayName”: “Old Name”
}

Monitoring shows:

• Primary write latency → healthy

• Replica lag → 250–800ms

• API latency → healthy

• Error rate → 0%

Yet users think the system is broken.

Existing Code:

---

📢 Get actionable Java and Spring Boot insights every week, including practical code tips and real-world, use-case-based interview questions, to help you level up your backend skills—join 7000+ subscribers for hand-crafted, no-fluff content.

First 100 paid subscribers will get the annual membership at $50/year forever that is ~ $4/mo ( 84 already converted to paid, 16 sport remaining)

So far we have covered 58 real world based interview questions and will add up to 100 by end of this year.

Testimonials

---

What do you think possible reasons for this behavior?

The system seems to be exhibiting a Read Your Own Writes consistency violation due to replication lag.

When writes committed successfully on primary,

PUT /users/123
  
@Transactional
public void updateUser(...) {                         
    user.update(request);
} 

Application thread
   ↓
Hibernate flushes SQL
   ↓
PostgreSQL primary commits transaction
   ↓
COMMIT acknowledged    

Replica replication is asynchronous. PostgreSQL replicas typically replicate via: Write-Ahead Log (WAL) shipping / streaming replication

Flow:

Primary COMMIT
   ↓
WAL generated
   ↓
WAL shipped to replica
   ↓
Replica replays WAL
   ↓
Replica becomes up-to-date 

This is not instantaneous. Lag may be: 50 ms, 200 ms, 1 second or occasionally more under load. This is replication lag.

Immediate read hits stale replica. So overall sequence would look like:

PUT /users/123   → Primary updated
GET /users/123   → Replica queried immediately
Replica still replaying WAL
Old row returned

So here:

• The write succeeded.

• The read succeeded.

• But the replica has not caught up yet.

This is a consistency model problem and this violates read your own writes consistency. and architecture becomes eventual consistent.

How would you implement “Read your own writes“ consistency while still benefiting from read replicas?

Solution 1 : Request Context Routing (Simple + Effective)

After a write: route subsequent reads to primary.