Почему интеграционная БД это отстой

Один из не упомянутых плюсов shared db: вы можете использовать поддержку целостности данных на уровне одной бд, foreign keys, triggers, вот это все.
Если вам надо добавить табличку, где есть FK на пять других табличек, не надо плясать с бубном как сделать это консистенто.

Если у вас разные сервисы работают с shared db, неплохо бы разделить их на юзеров с соотв. правами. Иногда писать/лочить определенную табличку и не требуется более чем одному сервису, что также уберет ряд проблем.

> если один из них добавит новую колонку в таблицу users с NOT NULL другой будет моментально сломан

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

Автору следует познакомиться с такими вещами, как:

• распределенные БД, обеспечивающие взаимодейсивие между разными экземплярами целевой бд (разные сервисы взаимодействуют со своей копией)

• горизонтальная и вертикальная проекция. для локализаци и разграничения прав доступа и нотации предикатов отношений

• хранимые процедуры, обеспечивающие единый интерфейс взаимодействия с данными.

  acid принцип это единственный правильный принцип для реляционных баз данных. Всё остальное это костыли.

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

Если бы вы разрабатывали обычный монолит или сервис со своим хранилищем, то вы просто переименовали бы колонку в telegram_id, а также поправили код, который с ней взаимодействует.

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

один сервис занимается регистрацией пользователей через web, а другой регистрирует через реферальную программу

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

Скорее всего, я просто не допёр или выпустил из текста что-то важеое..

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

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

Суть ведь не меняется. У вас есть одна предметная область, но разные сценарии и требования, которые вызывают конфликты в моделях.  

Что вам сулит много хорошего: микросервисы, serverless, акторы? Допустим, микросервисы. Решать придётся точно такие же проблемы: 

• Менять API микросервиса страшно. Вам так же придется бегать по потребителям и проверять не используют ли они изменяемый API. 

• Точно так же у вас появится shared микросервис. Если им владеет другая команда, вы получите все перечисленные организационные проблемы. 

• Отказавшись от shared базы в пользу микросервисов, вам придется так же отказаться от многих плюшек. Опытные DB девелоперы умеют аудит через механизмы СУБД, умеют генерировать динамический SQL, расширять возможности базы, гибко настраивать политики доступа, встраиваться в аналитические системы и прочее. 

• Объединять потоки коммуникации микросервисов тоже становится невозможно или очень сложно. Например, у вас один сервис GraphQL, другой REST, а третий gRPC. Новая команда аналитики хочет получить доступ к некоторым данным в потоке из этих сервисов. Им вместо банальной выгрузки из базы придется писать адаптеры для всех перечисленных протоколов. Или идти напрямую в хранилища этих сервисов... Oh, wait! Это же нарушение инкапсуляции. 

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

Так что пока эти решения не найдём, называть shared базу данных антипаттерном рановато. 

Кто б автору про ESB технологии рассказал, про архитектуру данных, проектирование интеграции.....

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

Практически не существует плохой архитектуры, есть только неумение её готовить или попытка натягивания её туда где она ну уж совсем не к месту.

И заголовок бы привели к какому одному поняитию.

Есть интеграция на уровне БД

Есть шаблон общая БД.

И есть интеграционная БД, про которую в статье нет вообще ничего.

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

А зачем работать с запросами? Наверное проще работать с хранимыми процедурами. И там уже работать с колонками или таблицами.