Ну я уже немного троллю его. Просто ему нужно гуглить, а не рассуждать о дублировании.
https://ru.wikipedia.org/Микросервисы

Я не эксперт в этом, потому я не скажу, лучше ли они справляются в этом деле чем клиентская аппликуха (но возможно тут я соглашусь, так как у тригерров данные с которыми они будут работать имеют вероятнсоть быть более персистентными чем в апликухи). Но опять же, я тут поднимал вообще другую тему, применимость всех этих извращений(триггеров, процедур, планировщика, расчет времени в СУБД) в повседневных задачах программиста.

Valick, ну в принципе, я с тобой согласен.

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

Ну да, у тех кто не дорос (не в обиду сказано), часто бывает бзик по поводу целостности данных, ведь они еще ничего не слышали о eventual consistency и распределенных систем не писали. Распределенные приложения вообще никогда не бывают в согласованном состоянии в один момент времени. Например все видели, что с банковского счета списывают средства сразу, но на другом они появляются только спустя N времени. Всё это время целостность данных нарушена.

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

Ок. В монго нет триггеров. По твоему у неё проблемы с целостностью данных или может всё же проблемы у программиста?

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

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

Я вас прошу, не топите себя. Ваше "по определению" не верно. Cassandra, DynamoDB и еще куча баз данных тоже nosql, но поддерживают триггеры. Даже для монго фанатами написаны костыли добавляющие триггеры.

Я вам еще раз повторяю, что средства списываются сразу. Зачисляются спустя время. Eventual consistency ответит что нет. а на самом деле - тоже нет. понимаете?

Eventual consistency это не что-то из мира nosql. Это просто подход. И может применяться в контексте реляционных, графовых, объектных и каких угодно баз данных.

Вы написали про целостность данных. Я вам немного рассказал, что целостность она разная бывает. И что поддерживать её можно другими средствами, без размазывания логики между бекендом и базой.

опишите тогда эти подходы.

Я уже писал, использовал если бы не было бекенда как такового, но кое какая минимальная логика присутствала. Можете ознакомиться почему триггеры это зло http://allthingsoracle.com/the-problem-with-triggers/

Посмотрите, что пытается сделать ТС. Для решения его задачи не нужен триггер. Ему нужно сделать это в приложении внутри тразакции. Никто потом при рефакторинге не вспомнит, что кто-то N времени назад добавил триггер. Даже сам этот кто-то не вспомнит. И потратят кучу времени на деббагинг, прежде чем поймут, что за чудеса происходят. Остальное проблемы, которые вам могут подарить триггеры, читайте в статье, ну или гуглите. Найдете то, что подавляющее большинство хейтят триггеры и с ними невозможно не согласиться.

Я уже писал. Нужна целостность - используйте транзакции, если распределенное приложение - используйте eventual consistency.
Нужно устранить дублирование - используйте SOA/микросервисы. Сделайте вместо триггера сервис и пусть другие сервисы обращаются к этому сервису, когда им нужно выполнить данную функциональность.

Всё это гуглится за несколько секунд, во всех подробностях.