Аудит в микросервисной архитектуре

По ссылке Pattern: Database per service описаны преимущества такого подхода:

• "Уменьшается связность между сервисами, можно независимо менять схему данных." - но это действительно хорошо, когда схемы данных для сервисов разрабатываются полностью независимо? В них могли бы использоваться общие справочники, общая схема именования таблиц, столбцов. Профит от того, что за всю схему данных отвечает один человек или группа людей мне понятен: потом эти данные проще анализировать, проще строить по ним отчеты, не нужно писать сложные ETL процедуры для приведения данных к единому виду, нет дублирования данных, схема данных достаточно устойчивая и не приходится всё переделывать при её изменении. Краткосрочный профит от распиливания схемы данных, ну, с натяжкой понятен: можно быстрее фигачить новые фичи в продакшен не парясь о схеме данных. Но в долгосрочной перспективе что потом с этими данными делать?

• "Каждый сервис может использовать свою СУБД". Очень важный пункт (sarcasm), хипстеры в каждой команде смогут использовать свои любые MongoDB, Neo4j или даже каждый месяц переходить на новую СУБД. Если серьезно я думаю, что в 2023 году такой зоопарк скорее минус, чем плюс.

Недостатки:

• "Сложнее реализовывать транзакции между микросервисами"

• "Сложнее join-ить данные из разных СУБД"

• "Сложнее админить разные СУБД" - если что-то упадёт и потом понадобится восстанавливать из бэкапов, то это выглядит просто страшным сном админов

Ну, ещё они забыли упомянуть:

• Сложнее обеспечивать целостность данных (внешние ключи)

• Сложнее реализовывать какие-то общесистемные вещи типа аудита, как вы описываете в статье

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

В подходе Database per service надо всё-таки подходить разумно к разделению. В микросервисе в первую очередь есть сущности с которыми он предназначен работать и за которые отвечает. Обычно одна-две плюс возможно несколько вспомогательных таблиц. А для "внешних" сущностей есть смысл иметь упрощённые таблицы реплики с минимально необходимым набором данных (обычно их действительно немного). Этого может вполне хватить, чтобы писать человекочитаемые события аудита с указанными в статье требованиями.

Если это не вариант, то всегда можно сделать микросервис для ведения событий аудита :)

Сколько работал, ни разу не попадалась ситуация, чтобы можно было разделить монолитную СУБД приложения на отдельные, слабо зависимые части. Как яркий пример: СУБД туристического агентства. Вроде бы и "да", разделить туристов с их паспортами, визами, и пр. персональными данными, маршруты и авиа компании с их ценниками и пр. ерундой, и т.д. Но, на практике, для менеджера тур-агентства наиболее часто востребованный кейс - это отчет "кто вылетает сегодня/завтра/через неделю, каким маршрутом, с какими документами, в каком количестве", дабы кому-то напомнить доложить визу, кому-то про дату вылета, кого-то забрать из дома и т.д. И сей отчет .. собирает 3/4 таблиц из БД тур-агентства.

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

Зато также не раз видел как легко, разделенная СУБД, дублируя данные приходит в полный абзац, т.к. forign key контролируется ПО, а не СУБД и накосячить можно легко, что называется "левой пяткой". И как ищут проблему искажения данных из-за програмно (не)реализованной транзакционности по полгода - тоже наблюдал не единожды.

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