Ох темнота... ты "клиенту" отдал данные и сказал: "вот теперь ты к этим данным ты можешь обращаться" (хоть в тот же момент, хоть время спустя) - и ты этот "контракт" обязан соблюсти (как ты его собираешься соблюдать никого не интересует - можешь хоть несколько уровней сделать). Ты когда базе говоришь "ты давай в таблицы вставляй (insert) и мне результат давай (commit)" - это точно такой же контракт, но в отличии от твоей поделки здесь совершенно понятно что в базе происходит, т.е. мы точно знаем кто нам враг:
- конкуренция за блок таблицы
- конкуренция за блоки индексов
- частые коммиты

можешь врубить в постгресе asynchronous commit (пусть DBA поржут), а можешь конкуренцию уменьшить.

ты клиенту пообещал, а сам не записал - это значит что ты все просрал. Ничего не мешает клиенту сказать: ты тут секунду подожди, я еще от остальных данные подожду и все разом залью.

потому что ты даже самые очевидные (ну там действительно код пописать нужно) варианты не рассматриваешь, а вместо этого уже решил какую-то дичь использовать.

Причем тут вообще гарантии доставки (в MQ это вообще означает что если интернет не работает, то пошлют голубиной почтой) и транзакционность? Ты клиенту ID дал, значит он может по нему обратиться (кафка в чистом виде тебе такого не позволит). ты погугли про все это: JMS, например, умеет в XA-транзакции участвовать (XA медленно, то что-то гарантирует), а у кафки есть менеджер транзакций, то там существенные послабления, кроме этого ни там ни там читать по PK нельзя. Хочешь чтобы все по чесноку было - пиши код.

ну значит пиши код простой как топор: с одной стороны вставляем в очередь, ждем когда флаг с false на true сменится и отдаем клиенту, а с другой стороны выгребаем очередь (или сколько за секунду набъется), сливаем все в базу и выставляем флаг в true. Контракты соблюдены, в базе конкуренции нет.

"сразу" нигде не бывает, тем более в интернете, а если ты и три минуты можешь ждать, то зачем было топик заводить? Продолжай бомбить базу в 600 потоков и ныть что постгрес не справляется (а здесь никакая база и 50 не выдержит вне зависимости от "железа")

тут же код писать нужно, а чтобы в кафку слить мусор и контракт не соблюсти - код писать уже не нужно.

ну ты больше слушай что говорят Если брать лидера в RDBMS (а не второй дивизион как у тебя - там народ вообще особо упорот на почве чистоты кода, поэтому ожидать чего-то сверхъестественного не стоит), то чтобы базе соблюсти вышеописанный контракт, ей нужно сделать вот что:
oracleWhen a transaction commits, the following actions occur:
- The database generates an SCN for the COMMIT. The internal transaction table for the associated undo tablespace records that the transaction has committed. The corresponding unique SCN of the transaction is assigned and recorded in the transaction table. See "Serializable Isolation Level".
- The log writer process (LGWR) process writes remaining redo log entries in the redo log buffers to the online redo log and writes the transaction SCN to the online redo log. This atomic event constitutes the commit of the transaction .
- Oracle Database releases locks held on rows and tables. Users who were enqueued waiting on locks held by the uncommitted transaction are allowed to proceed with their work.
- Oracle Database deletes savepoints.
- Oracle Database performs a commit cleanout. If modified blocks containing data from the committed transaction are still in the SGA, and if no other session is modifying them, then the database removes lock-related transaction information (the ITL entry) from the blocks.
- Oracle Database marks the transaction complete.


Вот если забить болт на то что у тебя 600 потоков вызывают бешеную конкуренцию (смотри видосик кстати про конкуренцию: