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

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

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

итого, как я вижу асинхронку тут? мы сформировали ответ, и один экземпляр бросили клиенту, второй экземпляр - в очередь. перед базой стоит что-то что эту очередь планомерно выгребает и складывает результаты в базу.

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

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

600 в секунду и всё заваливается.

это всё равботает до тех пор пока тебе клиенту скажем не надо вернуть айдиху сущности которую назначает база.

клиенту возможно нужен айди чтоб создать новую сущность которая имеет связь с ранее созданной и сохраненной.

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

ну я хз. у меня в реальном трафике ж еще и селекты. селекты плюс инсерты инсерты где то треть. как обычно но там и парой тысяч не пахнет. железка неплохая. а ты про 250к говоришь.

какой батчинг? я не с файлика данные копирую.

Что там за железо чтоб тащить 250ксек?
Майтон я все понимаю за постгрес но его потенциал роста вверх в моем случае исчерпан. Вот и чешу репу чтоб и два горошка скушать и на стул сесть

я попробую снять стату с базы. у меня в среднем летит 300 рест запросов что порождает 600-900 инсертов и какое то количество селектов (минимум 300). далее, не понял, при чем тут транзакционность? и откуда выводы что я ее похерил? атомарные операции (по логике атомарные) у меня выполняются внутри транзакций. это вроде как очевидная вещь о которой говорить и не следует.

по поводу конфиги. у меня бд не ссд (я хз что еще оказывается не ссд бывает но так девопсы сказали) 24 ядра хз сколько оперативки.
при озвучанных выше значениях начинает просто каждый последующий инсерт вставляться все дольше и дольше и так до 5-ти минут на простой инсерт!

то что в кавычках - поясняю. если пропадет 1% данных - то это не будет страшно. если пропадет 50% данных - то это плохо.
асинхронно писать - потому что я не вижу особо выхода. либо вертикально скейлить бд, либо думать всякую фигню с репликами. либо переписывать код. всё.

ну я по-сути хочу что-то такое же.