You imply that the process forks for each request received, and that the forked copy attempts to do an insert.

This is a strategy that is, IMHO, inherently unstable (and easily “flooded”).

A much better strategy would be to have an app that simply consists of two threads or processes:

• The main, or “listener,” thread waits for requests to arrive.   When they do, it writes a record to a queue.
• The child, or “writer” thread waits for a message to arrive in the queue, then posts it to the database.

So, if a flood of inputs comes in, they simply pile-up (briefly...) in the queue.   The writer-process disposes of them as quickly as it can ... while never overwhelming the underlying database server.   The listener-process can reply immediately, saying in effect that “your request has been accepted,” knowing that the writer will “lazily” post it to the database.   From the database server’s point of view, this app might be a “busy” client, but it is also an “uncomplicated” one.