How would you test concurrency issues when multiple users update the same address?

How would you test concurrency issues when multiple users update the same address?

• A. Lock the database table globally during updates.
• B. Use optimistic locking or version checks, simulate concurrent updates, and handle conflicts with clear messages.
• C. Ignore concurrency and resolve conflicts with manual intervention.
• D. Always clone the address to a new row before any update.

Answer: (B)

When testing concurrency, you want a method that detects conflicts without blocking everyone or creating duplicates. The best approach is optimistic locking with version checks, plus simulating concurrent updates and returning clear, actionable messages when conflicts occur.

Optimistic locking works by giving each address row a version (or timestamp) that increments with every successful update. When a user reads the address, they also read the current version. When they submit an update, the system checks that the version they sent matches the current version in the database. If it matches, the update proceeds and the version bumps. If it doesn’t match, it means another update happened in the meantime, so the system detects a conflict.

Testing this involves simulating two or more concurrent updates against the same address. For example, two sessions fetch the same address with the same version, then both attempt updates. The first update succeeds and increments the version; the second finds the version mismatch and is treated as a conflict. This demonstrates whether your system can detect and handle collisions.

Handling conflicts with clear messages is key. When a conflict is detected, you can present the user with the latest current values, explain that someone else updated the address, and offer options to retry, review changes side-by-side, or merge edits. This preserves data integrity while keeping the user informed.

Why the other options aren’t ideal: locking the table globally blocks all other users and harms scalability; leaving concurrency unhandled risks inconsistent data and a poor user experience; cloning the address to a new row creates duplicates and messy history, which is usually not desirable for the canonical address record.