Spring Boot Interview Quiz : Why Is CPU Low but Latency High?
Can you spot the hidden scalability bottleneck?
Context
Your application reserves inventory
During a flash sale:
Application CPU stays below 20%
Database CPU stays below 30%
API latency jumps from 80 ms to 12 seconds
Thread dumps show many threads blocked inside
findById()
What is the BEST explanation?
A. Spring Data JPA is leaking database connections.
B. The pessimistic lock is held while the external payment validation executes, forcing other transactions to wait.
C. Hibernate retries failed transactions automatically.
D. The database optimizer stopped using indexes because of the lock.
🚀 Level up your Java & Spring Boot skills.
Join 8000+ developers and get weekly, no-fluff content featuring practical coding tips, real-world backend insights, and interview questions based on production scenarios.
Founding Member Offer: Lock in founding member price at $50/year (~$4/month) for life. Limited spot left.
See what readers are saying 👇
Answer
B.
PESSIMISTIC_WRITE acquires an exclusive row lock as soon as the row is read.
The transaction then performs a slow network call:
paymentGateway.validateCustomer();Since the transaction hasn’t committed yet, the row lock remains held during the external API call.
Every other purchase for the same product waits for that lock to be released.
The result is:
Low CPU utilization
High response time
Growing thread pool
Long database lock wait times
The bottleneck isn’t computation, it’s waiting.
Some other important points
1. Lock Duration Matters More Than Lock Type
Holding a lock for 50 ms is very different from holding it for 5 seconds.
The real issue is that the transaction includes slow I/O.
2. Never Perform Remote Calls While Holding Database Locks
Bad:
Better:
Throughput Calculation
If one purchase takes 2 seconds while holding the lock:
Even though the servers appear mostly idle.
What we should monitor?
Database lock wait time
Active transaction duration
Connection pool utilization
Slow query logs
Thread dumps
Blocking sessions (
pg_locks,SHOW ENGINE INNODB STATUS, etc.)
Better Alternatives (Depending on requirements)
Optimistic locking with retries
Atomic SQL update:
UPDATE product
SET quantity = quantity - 1
WHERE id = ?
AND quantity > 0;Inventory reservation queue
Thats all for this week friends! Thanks for reading this far. If you liked it please share with your network.
Happy Coding 🚀
Suraj
Subscribe | Sponsor us | LinkedIn | Twitter | Youtube