this->notes.

#highload

Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).

Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.

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

Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
1️⃣ Если вы молодой стартап и торопитесь сделать хоть что-то работающее, то не заморачиваться с поднятием отдельной БД может быть сильным срезанием в сроках.
В т.ч. не нужно делать API и учиться в него ходить.
2️⃣ Если вы в процессе распила монолита (strangler паттерн), это может быть естественным шагом развития вашей системы.
3️⃣ Если у вас уже есть одна фулл настроенная БД, то иметь желание сократить ресурс на администрирование второй вполне естественно (актуально для команд с небольшой экспертизой и слабой инфрой). Также можно экономить на лицензиях и железе в целом.

Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
1️⃣ У сервисов с общей БД связность (или coupling) мгновенно возрастает до небес.
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
2️⃣ Нарушаем инкапсуляцию.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
3️⃣ Масштабироваться сложно.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.

Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.

Please open Telegram to view this post

VIEW IN TELEGRAM

Please open Telegram to view this post

VIEW IN TELEGRAM

❤18👍18

www.tgoop.com/thisnotes/363

8.62K viewsSep 15 at 07:25

#highload

Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).

Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.

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

Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
1️⃣ Если вы молодой стартап и торопитесь сделать хоть что-то работающее, то не заморачиваться с поднятием отдельной БД может быть сильным срезанием в сроках.
В т.ч. не нужно делать API и учиться в него ходить.
2️⃣ Если вы в процессе распила монолита (strangler паттерн), это может быть естественным шагом развития вашей системы.
3️⃣ Если у вас уже есть одна фулл настроенная БД, то иметь желание сократить ресурс на администрирование второй вполне естественно (актуально для команд с небольшой экспертизой и слабой инфрой). Также можно экономить на лицензиях и железе в целом.

Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
1️⃣ У сервисов с общей БД связность (или coupling) мгновенно возрастает до небес.
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
2️⃣ Нарушаем инкапсуляцию.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
3️⃣ Масштабироваться сложно.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.

Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.