**Question:** Can this API endpoint handle concurrent writes without data loss?

I am integrating a third-party REST API and need to confirm their concurrency model for POST/PUT requests — do they implement optimistic locking (ETags), pessimistic locks, or is it first-write-wins with potential overwrites?

It depends on your isolation level and how you're handling write conflicts. If you have transaction_isolation = SERIALIZABLE, the DB will throw a serialization error for concurrent writes, and you need to retry the operation in your application code with exponential backoff.

If you're at REPEATABLE READ or lower:

• Lost updates: two transactions read value A, both write B1/B2 based on A — one overwrites silently. Fix: use UPDATE ... WHERE version = @version (optimistic locking) or a SELECT FOR UPDATE (pessimistic).
• Phantom reads: another transaction inserts rows matching your query's criteria while you're processing. Less likely to cause data loss, but can skew aggregate logic.

If this is high-volume and you don't need strict consistency, consider:

1. Event sourcing — append-only writes with a projected read model (no merge conflicts possible). 2

It depends on which storage engine and isolation level you're using. If it's Postgres with default READ COMMITTED, concurrent writes to different rows are safe but race conditions can occur on read-modify-write cycles. You should add:

1. SELECT ... FOR UPDATE for locking specific rows during a transaction
2. Optimistic concurrency control (WHERE version = :old_version) if collisions are rare
3. Database-level unique constraints to prevent duplicate creation from race conditions

If this endpoint performs an aggregate update (e.g., incrementing a counter), use SET count = count + 1 directly in the SQL instead of fetching, modifying, and saving — let the database handle the atomicity.

This is one of those questions that gets asked every three weeks by people who haven't bothered to read page 42 of the docs or look at issue #817 on GitHub where we already documented this.

The endpoint uses a standard distributed lock with a 50ms TTL