When multiple PHP workers can execute a task on the same resource at the same time, a lock can reduce duplicated work. This is commonly considered when generating a report, processing an order, or updating a shared resource. But using Redis does not, by itself, make an operation consistent: the process can pause, the lock can expire, and another worker can start before the first one finishes.
The important decision is not just how to create a key, but which property needs protection and which system can enforce it. In many cases, a unique constraint or a database transaction provides a more direct guarantee. Distributed locks with Redis in PHP are useful when they coordinate processes that cannot be handled with a single atomic database operation, as long as they are designed as temporary protection and not as the ultimate source of truth.
What a distributed lock solves—and what it doesn't guarantee
A distributed lock allows multiple processes, possibly on different servers, to compete for temporary mutual exclusion. If a worker acquires the lock, the others should refrain from entering the critical section while it remains valid. This is useful, for example, to prevent two processes from starting an expensive task simultaneously or to coordinate work that affects external services.
The lock does not, on its own, guarantee that only one write will occur, that the owning process is still alive, or that Redis and the database maintain a consistent state. It is a temporary grant, similar to a lease. If the worker stops for longer than the lease duration, Redis may allow another worker to acquire the lock even though the first worker continues working when it resumes.
For this reason, an application should not rely exclusively on the Redis key to protect a business rule. The final operation must have its own safeguards: validations, integrity constraints, version checks, or idempotency, as appropriate.
When to use Redis and when to choose the database
Before adding a lock, identify the condition you want to preserve. If the goal is to prevent an entity from having two records with the same identifier, a unique database constraint expresses and enforces that rule where the data is written. It does not depend on every worker following an external protocol.
If several changes must be committed together, a transaction may be sufficient. To avoid overwriting a concurrent update, optimistic concurrency control may be a good fit: read a version, update only if it has not changed, and handle the conflict explicitly. For operations on rows or data sets, pessimistic locking in the database itself may be more appropriate, though its scope and duration should be limited.
Redis can be a good option when mutual exclusion coordinates work across processes and no single database operation can handle it, or when you need to prevent many workers from starting a repeated task at the same time. Also assess whether the cost of waiting, retrying, and operating Redis is justified. If a unique key solves the problem with fewer components, it is usually preferable.
Atomic acquisition, a unique owner, and expiration
Acquisition must be a single atomic operation: create the key only if it does not exist and assign it an expiration in the same operation. In Redis, the usual pattern uses SET with the options equivalent to “only if it does not exist” and a time to live. Separating key creation from assigning its expiration opens a race: the process could fail between the two and leave a lock that never expires.
The key's value should be a unique token generated for that attempt, not a constant shared by all workers. The token identifies the owner and prevents a process from accidentally deleting a lock subsequently acquired by another process. The PHP client should treat the lock as acquired only if Redis confirms that the conditional operation succeeded.
// Conceptual outline; adapt the call to the Redis library in use.
$token = generateUniqueToken();
$acquired = redisSetIfNotExistsWithExpiration($key, $token, $duration);
if (!$acquired) {
// Do not enter the critical section.
}The expiration should exceed the expected duration of the work, but should not be so long that a failure leaves other processes waiting unnecessarily. There is no universal value: measure actual duration, account for variation, and define what to do with work that approaches the limit. Renewing a lease also requires checking that the token is still the owner; a blind renewal could extend another worker's lock.
Safe release and expiration risks
Do not simply delete the key when finished. If the original lock expired and another process acquired a new one, the first worker could delete the second worker's key. Release must compare the stored value with the owner's token and delete the key only if they match, as an atomic operation. This can be implemented with a script executed in Redis or an equivalent primitive that compares and deletes without interleaving operations.
Even with correct acquisition and release, a long process pause can lead to concurrent writes. Worker A acquires the lock, is suspended, and its lease expires; B acquires the lock and writes; A resumes and also writes. Worse, a network partition or connection failure may leave the client unsure whether the acquisition operation was executed.
If a late write could cause damage, the protected resource must reject it independently. One strategy is to use a fencing number or an increasing version and require the system receiving the write to discard older values. That counter must have the ordering and durability properties the use case requires; a Redis counter, without accounting for restarts or failover, should not automatically be assumed to provide that guarantee. Another option is to check a version in the database as part of the write operation itself.
Critical section, contention, and acquisition failures
Keep only the work that genuinely requires mutual exclusion inside the lock. Avoid including slow calls to external services, user waits, or independent processing. The longer the critical section lasts, the greater the contention and the chance of exceeding the expiration time. If the work can be split up, separate brief coordination from tasks that do not depend on the shared state.
If the lock cannot be acquired, avoid retrying indefinitely or tying up PHP workers with long waits. Define a policy based on the importance of the work: abandon it and log the conflict, retry with a limited wait, or send the task to a queue for later processing. Retrying must be safe and idempotent, and the system must distinguish normal contention from a Redis failure.
When the connection state is uncertain, do not assume either that the lock was acquired or that it was not. Design the flow to recover without executing an irreversible action twice: for example, use idempotency keys for the business operation and check its result before repeating it.
Testing and operational signals
Test behavior with multiple workers and exercise different interleavings, not just the happy path. Include scenarios in which the process exits before releasing the lock, expiration occurs during the work, Redis does not respond, and an old worker tries to release the lock after another worker has acquired it. Verify that the token prevents deleting a lock owned by someone else and that late writes are rejected when the application requires that guarantee.
In production, monitor failed acquisitions, critical-section duration, expirations, renewals, connection errors, and retries. A rising contention rate may indicate that the lock's granularity is too broad or that more work than necessary is being done inside it. Frequent expirations during normal tasks indicate that the lease duration or process design needs review—not simply an automatic increase to the TTL.
Decision checklist
- Which business rule is being protected, and can it be expressed with a database constraint or transaction?
- Is acquisition atomic and conditional, and is it paired with an expiration?
- Does each attempt have a unique token, and does release check the owner before deleting?
- What happens if the process pauses longer than the lease or Redis loses its connection?
- Can the system receiving the write reject old versions or duplicates?
- Is there a limited wait, retry, and recovery policy, along with metrics and concurrency tests?
Redis provides temporary coordination, not a universal consistency guarantee. Use it when the problem genuinely requires coordinating distributed processes, and keep ultimate protection in the system that writes the data. If the rule can be enforced more simply in the database, start there.
