Synchronization Across Distributed Servers: DB vs Redis vs Actor

In distributed systems, one of the most common and tricky challenges is ensuring synchronized access to shared resources across multiple server instances.

For example, when a user initiates a money transfer, updates a shared task list, or interacts with a counter, the request may hit any instance in your cluster. Unless synchronized properly, this can result in race conditions, inconsistent state, or data corruption.

Traditional Synchronization Techniques

Developers typically reach for one of two well-known approaches:

1. Database Locking

Using pessimistic locking (SELECT ... FOR UPDATE) or JPA's @Lock(PESSIMISTIC_WRITE):

• Simple and widely supported
  


• Ties up database connections
  


• Increases contention and slows down unrelated queries

2. Redis Locks

Using a distributed lock pattern (e.g., Redlock via Redisson):

• Offloads lock state from the DB
  


• Requires Redis infrastructure
  


• Needs careful retry/backoff handling to be safe and reliable

Both methods require additional complexity and infrastructure to maintain, especially at scale.

A Simpler Alternative: Clustered Sharded Actors

Thanks to spring-boot-starter-actor, there's a third option: actor-based synchronization with no external system required.

The library integrates Apache Pekko cluster sharding into Spring Boot, enabling you to model shared entities as singleton actors across your cluster.

If two concurrent requests targeting the same logical ID (like user-123) arrive at different servers, the actor system ensures that:

• Only one instance of the actor is created for that ID
  


• All messages for that ID are routed to and handled by that actor, sequentially

This eliminates the need for locks or external coordination.

Real-World Comparison: DB vs Redis vs Actor

We compared three implementations of a synchronized counter increment:

• 
  db: Uses pessimistic DB locking
  


• 
  redis: Uses Redis-based distributed lock
  


• 
  actor: Uses spring-boot-starter-actor’s sharded actor system

Test Setup

• 3 Spring Boot instances (ports 8080, 8081, 8082)
  


• Each instance received 3,000 concurrent POST requests (total: 9,000)
  


• Each method was benchmarked independently using Apache Bench (ab)
  


• Final value was retrieved via: GET /counter/{method}/{counterId}
  

Results Summary

Although many requests technically "failed" at the HTTP layer (due to thin responses or benchmarking artifacts), the counter logic worked perfectly in all cases.

Why the Actor Model Is Effective

Using actors for synchronization offers several advantages:

• 
  Correctness: Each logical ID maps to a single actor that serializes access
  


• 
  Simplicity: No retry logic or lock expiration handling
  


• 
  Infrastructure-free: No Redis or lock coordination service needed
  


• 
  Scalability: Naturally distributed across nodes without contention
  

This model fits naturally into workloads where each entity (e.g., user, session, document) can be isolated and updated independently.

How to Get Started

Refer to the examples.

Summary

If you're building a distributed Spring Boot system and need reliable, low-latency synchronization without operational burden, consider giving the actor model a try.

Source Code

You can find the complete working example, including the benchmarking script, on GitHub:


🔗 spring-boot-starter-actor — Synchronization Example