Distributed Synchronization

Normal C# locks only work inside one process. But what if you have 10 instances of a service and you need only ONE of them to process a shared resource? You need a Distributed Lock.

1. Redis as a Lock Manager

Redis is perfect for this because it's single-threaded and fast. We can use the `SET NX` command to "Claim" a lock key. If the key exists, the second instance fails to get the lock. **Architect Rule:** Always set a **TTL (Time To Live)** on your lock so that if the service crashes, the lock is eventually released and the system doesn't stay frozen forever.

2. Redlock Algorithm

For mission-critical locks (where one Redis server failing could be a disaster), we use **Redlock**. It requires getting a lock from the majority of Redis nodes. While more complex, it provides a 'Fault-Tolerant' way to ensure that even during a cluster failover, your critical business logic remains synchronized.

4. Interview Mastery

Q: "Why should you avoid distributed locking if possible?"

Architect Answer: "Because it introduces **Performance Bottlenecks** and **Deadlocks**. Every lock is a point of contention. Whenever possible, I prefer to use **Optimistic Concurrency** (Version numbers/ETags) or **Idempotent Logic**. Distributed locks should be a 'Last Resort' for when you truly cannot solve the race condition through data design."