The database can only hold 1 write concurrently and does not support transactions. If this value is exceeded, the database responds immediately with an error code XXXXX.
This is extremely bizarre for any modern database, but let's accept the premise.
At a high-level, there are 2 approaches to concurrent data modifications:
Pessimistic - This is lock-based, which will acquire a lock on a resource before modifying it, and release the lock afterwards. If another process has that resource locked, requests to acquire a lock on that same resource will block. This basically serializes updates to this resource. I am intentionally being vague when I say resource, because it is somewhat ambiguous. Simplistically, a resource is usually a row in a database table, but it can also be pages/blocks, ranges, or entire tables (the specifics of this vary from one DBMS to another).
Optimistic - Locks are never acquired, but when updating data, there is an implied if-it-has-not-changed-since-i-read-it stipulation and if that stipulation is violated, an error will be thrown. (Sometimes this is implemented by literally comparing old values to new values, or by comparing a hash code, version number, etc. Details are irrelevant at this level).
Since you are getting an error on concurrent inserts, I suspect you either have the latter, an optimistic concurrency strategy in place, or you have some wonky DBMS that simply does not support concurrent updates whatsoever. If using optimistic concurrency, then, however that was setup, it is a poor use case for it. Optimistic is, well, optimistic. It assumes that updates and overlapping changes are rare, so it optimizes for the common case (very efficient reading) at the expense of rare cases (conflicting changes). If you are hitting a bottleneck where inserts are regularly failing due to such a case, then your read-write ratio is better suited to pessimistic locking.
Long-story short, whatever the reason is, the solution is the same: these inserts need to be serialized. Some of these answers on this question suggest message queues or dropping to a single server (which, by the way, I don't think will really solve the problem...), using Hazelcast to do cross-server locks, etc. They are all variations of the exact same thing: serialize the inserts!
The fact is, any ACID-compliant DBMS will handle this for you automatically. If you are using an ACID-compliant DBMS, but using optimistic concurrency (some sort of a
version field, probably?), take that out. Switch to plain
delete without any versioning and see if that solves your problem.
If you are not using an ACID-compliant DBMS, then my recommendation is to switch to a better database. Yes, you can solve this through other means (like Hazelcast, message queue, etc.), but they either add single points of failure or re-invent database locking. Frankly, that scares me. Proper database locking is an extremely complicated subject with armies of engineers with PhD's designing it. I would never want to re-invent it myself. That is a waste of my time. It would be cheaper to change databases.
For questions like this, it would be good to specify the database software you are using. I am skeptical that your database really has this limitation. It's like a highway which only allows one car at a time.