Привіт,

Ось це потребує rethink-у майфренд )
У мене це частина роботи: девелопери нерідко далекі від розуміння алгоритмічної складності або даунтайма від міграції (альтера, або блокуючого апдейта), або наслідків поведінки код->платформа->база.

Ну і ситуація із чергами вона таке собі: якщо ти в коді поклав, то дуже часто зустрінеш конструкцію перевірки і ассерт "покласти ще раз" until execution timeout kill + repeat лоад балансером вбитого запита ще раз на іншій ноді = вставка одного і того ж багато-багато раз, якщо це не хендлиться трігером (і дедлоком поруч бгггг), або (ще гірше) - унікальним ключем по Х рядкам (один з яких може бути NULL, буде NULL і знову будуть дублікати :-)

Тобто роль окремого ДБА, який розуміє наслідки вона не перекривається опсом/лідом.

Я далекий від думки розповідати авторам софта як треба писати софт, але якщо БД недоступна, то в неї не треба писати. А якщо все ж таки пишеш - то не треба вважати, що воно записалось. Якщо у тебе йде потік вхідних даних - складай його в тимчасовий файл. Клади в чергу. Варіантів безліч, але дивно розраховувати, що якщо ти зробив echo "Hello!" > /dev/null, то cat /dev/null поверне тобі "Hello!" :-)