Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Jobs Across Multiple Instances: Distributed Locks, Leader Election and Double Execution
A BackgroundService in three replicas produces the nightly report three times; a lock taken through DistributedLock on SQL Server sp_getapplock, a PostgreSQL advisory lock or Redis brings that down to one. When the lock's owner dies by kill -9, on Redis nobody holds the lock until the 30-second lease ends; on PostgreSQL it stayed with the dead process until the server noticed the dropped connection, about a minute in my test. A lock isn't a guarantee, it's a lease.
Distributed Locks, Leases and Fencing Tokens: Why a Lock Is Not Enough
A time-limited lock (a lease) does not guarantee correctness on its own: if the holder hits a GC pause, the lease expires, someone else takes the lock, and the first process still writes when it wakes up. In a run with real Redis and SQLite the stale report overwrites the new one; checking a fencing token that grows with every lock in the database with WHERE token > LastToken rejects the stale write. Both sides of the Redlock debate and the database's own mechanisms are covered too.