Day 26: Optimistic Locking with Versioning.

Welcome back, architects and engineers. We've spent weeks forging resilient, high-performance microservices, learning to isolate failures with Circuit Breakers (Day 20) and ensuring our systems can breathe under immense load. Today, we confront another silent killer in distributed systems: concurrent modifications.

Imagine a system handling 100 million requests per second. That's a staggering 100,000 requests every millisecond. In such an environment, multiple users, services, or automated processes are constantly trying to read and update the same piece of data simultaneously. Without proper controls, chaos ensues: lost updates, incorrect calculations, and ultimately, data corruption.

The Hidden Killer: Concurrent Updates and Why Pessimistic Locking Fails at Hyperscale

In a traditional, single-server application, you might use pessimistic locking. This is like putting a "Do Not Disturb" sign on a database row: when one transaction starts modifying data, it locks that row, preventing anyone else from even reading it until the first transaction completes.

While simple, pessimistic locking is a performance killer. At 100M RPS, if you lock even a handful of frequently accessed inventory items or user profiles, your system will instantly serialize requests, creating massive queues, timeouts, and bringing your throughput to its knees. It's like having a single-lane bridge for a 10-lane highway – a bottleneck of epic proportions. This is simply not an option for hyperscale.

The Zen of Optimistic Locking: "Assume Good, Verify Later"

This is where optimistic locking shines. Its intuition is beautifully simple and deeply pragmatic: assume conflicts are rare, proceed with your changes, but verify just before committing.

Instead of locking data upfront, optimistic locking allows multiple transactions to read and even attempt to modify the same data concurrently. How does it prevent corruption? By introducing a version number (or timestamp) to each piece of data.

Here's the magic:

1. When you read an entity, you also read its current version number.

2. You make your modifications to the entity in memory.

3. When you try to save the modified entity back to the database, the system checks: "Is the version number in the database still the same as the one I originally read?"

• If yes: No one else modified it. Your update proceeds, and the version number is incremented.

• If no: Someone else snuck in and updated the data after you read it but before you tried to save. Your update is rejected, typically throwing an OptimisticLockingFailureException.

This approach maximizes concurrency because locks are not held. Conflicts are detected only at the point of commit, and only conflicting transactions are rolled back, leaving the vast majority of operations to proceed unimpeded.

How @Version Works in Spring Data JPA

Spring Boot, with its JPA integration, makes implementing optimistic locking incredibly straightforward using the @Version annotation.

When you add @Version to a numeric field (like Long or Integer) in your JPA entity, Spring Data JPA automatically handles: