Команда "распилила" монолит на 6 микросервисов, но все пишут в одну PostgreSQL, используют JOIN между таблицами разных сервисов и выкатывают релиз одним пайплайном. Какой архитектурный риск здесь главный?
Anonymous Quiz
65%
Distributed monolith: формально сервисы разделены, но связаны через общую схему БД
16%
Нарушение принципа REST: внутренние вызовы должны идти только через методы, а не через общую БД
9%
Недостаточная отказоустойчивость: при падении одного pod Kubernetes не поднимет остальные реплики
10%
Отсутствие API Gateway — без него микросервисная архитектура считается невалидной
❤1
📖 Пояснение:
Это классический distributed monolith — худший из двух миров. Сложность микросервисов (сеть, версионирование контрактов, observability) уже есть, а выгоды MSA нет.
Признаки из вопроса:
▫️ Общая БД — главный антипаттерн MSA; граница сервиса = граница данных
▫️ JOIN между "сервисами" — скрытая жёсткая связность; изменение схемы ломает всех
▫️ Один пайплайн релиза — нет независимого deploy, команды блокируют друг друга
На собеседовании сильный ход — назвать это по имени и предложить: database per service, интеграция через API/события, отдельные CI/CD.
Почему не 2
Проблема не в выборе REST. Даже идеальные gRPC-контракты не спасут, если сервисы делят таблицы и миграции схемы согласуются вручную на весь зоопарк.
Почему не 3
Kubernetes поднимет реплики — это про оркестрацию контейнеров, не про логическую связность. Система может быть"живой" и при этом архитектурно неправильной.
Почему не 4
API Gateway не лечит shared database. Шлюз — фасад для клиентов. Без gateway MSA всё равно возможна — вопрос в границах доменов.
💡 Запомни формулировку для собеса: «Микросервисы без изоляции данных — distributed monolith»."
🔥7❤3
Сервис оплаты публикует событие «payment.completed» в Kafka с гарантией at-least-once. Консьюмер списывает бонусы. Из-за retry одно и то же событие может прийти дважды. Что аналитик обязан заложить в требования к консьюмеру?
Anonymous Quiz
80%
Идемпотентная обработка по бизнес-ключу payment_id: повторное событие не меняет баланс второй раз
16%
Переключить Kafka на exactly-once — брокер сам гарантирует уникальность на уровне всей цепочки
3%
Заменить асинхронную схему на синхронный REST-вызов с таймаутом 30 секунд между сервисами
0%
Отключить acknowledgment у консьюмера, чтобы сообщение не переотправлялось при сбое
❤5
📖 Пояснение:
At-least-once означает: сообщение дойдёт, но возможен дубликат (сбой после обработки, но до commit offset).
Решение на уровне бизнес-логики — идемпотентность:
▫️ Хранить обработанные
payment_id▫️ Или upsert с тем же ключом — повторный вызов даёт тот же результат
▫️ Это стандартное требование аналитика в ТЗ на интеграции через брокер
Почему не 2
Exactly-once в распределённой системе — сложная комбинация (транзакции Kafka + идемпотентный producer + координация с БД). «Брокер сам всё решит без дедупликации» — миф. Даже EOS в Kafka не отменяет идемпотентность на стороне consumer для внешних side effects (бонусы, деньги).
Почему не 3
Sync REST не убирает дубликаты — клиент может повторить запрос при таймауте. Проблема идемпотентности остаётся, плюс появляется coupling и каскадные таймауты по цепочке сервисов.
Почему не 4
Отключение ack усугубляет потери и хаос: при сбое offset не фиксируется, но отказ от ack не равно "не будет retry". На практике — риск потерять сообщения или обрабатывать бесконечно. Это антипаттерн.
💡 На Middle-собесе ждут связку: at-least-once → дубликаты возможны → idempotency key в ТЗ.
🔥9❤2
Мобильное приложение открывает экран «Заказ». API Gateway последовательно вызывает 5 микросервисов. p95 ответа — 4,2 сек, таймаут клиента — 3 сек. Какое архитектурное решение корректно заложить в ТЗ?
Anonymous Quiz
59%
BFF с параллельной агрегацией или выделенный composite endpoint, собирающий ответ за один round-trip
15%
Увеличить таймаут мобильного клиента до 10 секунд — проблема на стороне UX, не архитектуры
23%
Перенести всю бизнес-логику пяти сервисов в API Gateway, чтобы сократить сетевые вызовы
3%
Отказаться от Gateway и вызывать микросервисы напрямую с телефона — так меньше промежуточных hop'ов
❤2
📖 Пояснение:
Проблема — синхронная цепочка (latency суммируется: 5 × ~800 мс ≈ 4 с). Gateway как "тупой прокси" не обязан агрегировать — но кто-то должен.
Варианты в ТЗ:
▫️ BFF (Backend for Frontend) — сервис под мобилку, параллельно дергает 5 API (Promise.all / async), отдаёт один DTO экрана
▫️ Composite endpoint в доменном сервисе — GET /orders/{id}/screen внутри собирает данные
▫️ Параллель, а не последовательность — p95 падает до max(вызовов), а не sum(вызовов)
Почему не 2
Увеличение таймаута — костыль. Пользователь ждёт 4+ секунды на каждом экране — плохой UX и отток. НФТ по latency нужно решать архитектурой, не настройкой клиента.
Почему не 3
Перенос бизнес-логики в Gateway — антипаттерн "умный gateway". Раздувается компонент, смешиваются cross-cutting и domain logic, усложняется тестирование и релизы. Gateway = фасад, BFF = агрегация под клиента.
Почему не 4
Прямые вызовы с телефона в 5 микросервисов — хуже: больше round-trip'ов с мобильной сети, нет единой точки auth/rate limit, внутренняя топология светится наружу, CORS и безопасность усложняются.
💡 На собесе: "Gateway ≠ BFF. Для тяжёлых экранов — отдельный BFF с параллельной агрегацией".
🔥11❤4
На складе 1 товар. При сетевом разрыве между двумя зонами оба сервера одновременно оформляют заказ. Двойная продажа хуже, чем ошибка 503. Какой принцип из CAP-теоремы выбрать в НФТ?
Anonymous Quiz
67%
При разрыве работа с остатками только при большинстве реплик. Если кворума нет — ошибка
11%
Обе зоны принимают заказ, расхождения остатков исправятся позже фоновой сверкой
11%
Держать один дата-центр без репликации между зонами
11%
Показывать клиенту последний известный остаток без обращения к серверу
❤4
📖 Пояснение:
Бизнес-правило из вопроса: перепродажи недопустимы → важнее согласованность, чем доступность любой ценой.
При network partition:
▫️ CP: система откажет в записи/чтению, если нет большинства реплик (quorum) — клиент получит 503/409, но двойная продажа одной единицы не произойдёт
▫️ Это ближе к strong consistency / linearizability на критичном ресурсе
Примеры подходов: etcd/ZooKeeper consensus, БД с sync replication и правилом "не пишем без кворума".
Почему не 2
Классический анти паттерн: оба узла принимают заказ → две продажи одной штуки — как раз то, от чего бизнес отказался. Согласованность для остатков склада без компенсации = финансовые потери.
Почему не 3
Один DC без репликации не решает отказоустойчивость. Partition tolerance в облаке неизбежна. Это шаг назад по availability при аварии ЦОД, а не осознанный CAP-выбор.
Почему не 4
Клиентский кэш остатка — ещё слабее по консистентной работе: пользователь видит фантомный товар. Не заменяет серверную модель согласованности и не предотвращает race condition на двух репликах.
💡 CAP на практике: не зубрить буквы, а привязать к НФТ — "перепродажа vs 503" → CP на остатках.
🔥9❤3💯1
Последние пару недель мы начали экспериментировать с форматом контента.
Если раньше чаще были карточки с теоретической информацией, то сейчас стали добавлять больше настоящих рабочих кейсов аналитиков.
Например такие вопросы, которые вполне могут прилететь на собеседовании мидла или встретиться на проекте:
— как правильно проектировать интеграции;
— где узкое место в архитектуре;
— почему решение выглядит логичным, но создаёт проблемы в проде;
— какие варианты реально используются в компаниях.
Интересно понять, как вы это ощущаете 🙂
Если раньше чаще были карточки с теоретической информацией, то сейчас стали добавлять больше настоящих рабочих кейсов аналитиков.
Например такие вопросы, которые вполне могут прилететь на собеседовании мидла или встретиться на проекте:
— как правильно проектировать интеграции;
— где узкое место в архитектуре;
— почему решение выглядит логичным, но создаёт проблемы в проде;
— какие варианты реально используются в компаниях.
Интересно понять, как вы это ощущаете 🙂
🔥11❤4
Заметили ли вы изменения в контенте
Anonymous Poll
51%
Да, стало интереснее
31%
Да, стало сложнее, но полезнее
14%
Не заметил(а) изменений
47%
Хочу больше практических кейсов
11%
Хочу больше контента для джунов
🎙 Вышел новый выпуск подкаста «Аналитик за кулисами»
Тема выпуска — архитектура систем
Про то, как на самом деле рождаются IT-системы: от бизнес-идеи и Vision до требований, архитектурных решений, MVP и пилота
В гостях — Кирилл Егоркин, архитектор решений
Этот выпуск особенно хорошо зайдёт тем, кто хочет лучше понимать, почему системы проектируются именно так, а не просто запоминать термины вроде DDD, микросервисов, брокеров и C4
🆘 А для тех, кто хочет системно разобраться в архитектуре, — в ближайшие дни расскажем про обновлённые программы наших курсов
Будет два уровня обучения, чтобы каждый мог выбрать подходящий формат под свой опыт и задачи
А пока выпуск можно посмотреть и послушать здесь:
📱 VK Видео
📱 YouTube
📱 Apple Podcasts
📱 Яндекс Музыка
Тема выпуска — архитектура систем
Про то, как на самом деле рождаются IT-системы: от бизнес-идеи и Vision до требований, архитектурных решений, MVP и пилота
В гостях — Кирилл Егоркин, архитектор решений
В выпуске обсудили:
— зачем проекту Vision и кто его формирует;
— где заканчивается зона ответственности аналитика и начинается зона архитектора;
— какие артефакты нужны до разработки;
— почему бизнес часто приходит не с проблемой, а с уже готовым решением;
— когда выбирать монолит, а когда микросервисы;
— как системному аналитику начать мыслить архитектурно
Этот выпуск особенно хорошо зайдёт тем, кто хочет лучше понимать, почему системы проектируются именно так, а не просто запоминать термины вроде DDD, микросервисов, брокеров и C4
Будет два уровня обучения, чтобы каждый мог выбрать подходящий формат под свой опыт и задачи
А пока выпуск можно посмотреть и послушать здесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤3
Мой воркшоп прошел на ура! Рассказывала, как создавать продукт, который будет приносить деньги и нужен пользователям😎
А помимо воркшопа я соорганизатор сообщества аналитического клуба и мы проводили совместный воркшоп, где просили ребят написать ТЗ на снежинки. Было забавно, посмотрите как парень смеется на последних видео)
А помимо воркшопа я соорганизатор сообщества аналитического клуба и мы проводили совместный воркшоп, где просили ребят написать ТЗ на снежинки. Было забавно, посмотрите как парень смеется на последних видео)
❤12👏2