4871. При оформлении заказа нужно: зарезервировать товар на складе и списать деньги. Если списание не удалось, резерв должен быть отменён. Сервисы имеют свои базы. Какой паттерн обеспечит согласованность?
Anonymous Quiz
9%
Двухфазная фиксация (2PC)
78%
Сага (Saga) с компенсирующими транзакциями
13%
Распределённая блокировка
0%
Общая база данных
❤2
В примере:
Сервис склада резервирует товар.
Сервис платежей списывает деньги. Если ошибка → сервис склада компенсирует резерв (отменяет резерв).
Двухфазная фиксация (2PC) медленна и не масштабируется. Общая БД – антипаттерн.
Реальный кейс: В Uber используется Saga для согласования поездки: создание заказа, поиск водителя, списание средств. При сбое любого этапа запускается компенсация.
Вывод: Для распределённых транзакций в микросервисах аналитик должен требовать Saga с явными компенсациями.
Please open Telegram to view this post
VIEW IN TELEGRAM
4872. Команда разработки использует относительные оценки (стори-поинты) и проводит Planning Poker. Какой основной недостаток этого метода?
Anonymous Quiz
10%
Занимает много времени на каждой итерации
76%
Оценки не отражают реальное время в часах или днях
11%
Требует участия всех членов команды
4%
Не учитывает сложность задач
🤔1
Это метод относительной оценки трудоёмкости, где каждый член команды даёт оценку в стори-поинтах (например, 1, 2, 3, 5, 8, 13). Поинты отражают сложность, объём и неопределённостьзадачи, но не переводятся напрямую в часы или дни. Разные команды имеют разную «скорость» (velocity) – количество поинтов, которое команда закрывает за спринт.
Основной недостаток:
Поинты не являются абсолютной мерой времени. Две разные команды могут оценить одинаковую задачу в разные поинты. Даже внутри одной команды поинты не гарантируют точного перевода в часы, так как скорость может меняться (болезни, праздники, сложность интеграции). Бизнесу часто нужны прогнозы в реальных днях/часах, а не в абстрактных поинтах.
Почему не другие варианты?
A – Planning Poker не занимает много времени (обычно 15–30 минут на планирование спринта).
C – участие всех членов команды – это преимущество, а не недостаток.
D – метод как раз учитывает сложность через поинты.
Реальный кейс:
Команда оценила задачу в 5 поинтов, а другая команда – в 13. Скорость первой – 30 поинтов за спринт (2 недели), скорость второй – 50 поинтов. Реальное время разное. Бизнес, требующий сдачи к определённой дате, не может полагаться только на поинты.
Вывод: Аналитик должен объяснять стейкхолдерам, что поинты – это относительная мера для команды, а для прогнозирования сроков нужно использовать историческую скорость (velocity).
Please open Telegram to view this post
VIEW IN TELEGRAM
4873. Сервис А вызывает внешний API, который иногда начинает отвечать с ошибкой 500. Без защиты все вызовы ждут таймаута, исчерпывая ресурсы. Какой паттерн предотвращает повторные вызовы к проблемному сервису на заданный период?
Anonymous Quiz
13%
Экспоненциальный ретрай
69%
Circuit Breaker (предохранитель)
11%
Идемпотентный потребитель
7%
Dead Letter Queue
При синхронном вызове к нестабильному внешнему сервису каждый запрос ждёт таймаута (например, 30 секунд). Если таких запросов много, потоки приложения исчерпываются, и система перестаёт отвечать даже на свои внутренние запросы. Экспоненциальный ретрай (A) помогает при временных сбоях, но не защищает от длительной недоступности – ретраи всё равно будут исчерпывать ресурсы.
Что делает Circuit Breaker:
Замкнут (closed) – вызовы идут к внешнему сервису. Счётчик ошибок увеличивается.
Разомкнут (open) – при превышении порога ошибок (например, 5 ошибок за 10 секунд) все вызовы мгновенно возвращают fallback (кэш, сообщение об ошибке) без реального запроса к сервису. Это даёт сервису время на восстановление.
Полуоткрыт (half-open) – через заданное время (например, 30 секунд) пропускается один пробный вызов. Если успех – предохранитель замыкается, если ошибка – снова размыкается.
Реальный пример:
В Netflix, Hystrix (библиотека Circuit Breaker) используется для защиты от падения зависимых сервисов. Если сервис рекомендаций падает, предохранитель размыкается, и пользователь видит заглушку, а не бесконечную загрузку.
Что должен зафиксировать аналитик:
Порог ошибок (например, 5 ошибок за 10 секунд).
Таймаут открытого состояния (например, 30 секунд).
Fallback-стратегия (кэш, сообщение, пустой результат).
Вывод: Circuit Breaker обязателен для всех интеграций с внешними сервисами, чтобы избежать каскадных отказов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4874. В таблице «Заказы» есть поля: order_id, customer_id, customer_name, order_date, product_id, product_price. customer_name функционально зависит от customer_id, а product_price – от product_id. Какая нормальная форма нарушена?
Anonymous Quiz
15%
Первая нормальная форма (1НФ)
52%
Вторая нормальная форма (2НФ)
27%
Третья нормальная форма (3НФ)
6%
Нормальная форма Бойса-Кодда (НФБК)
1НФ – все атрибуты атомарны, нет повторяющихся групп.
2НФ – находится в 1НФ, и каждый неключевой атрибут зависит от всего первичного ключа (а не от его части).
3НФ – находится в 2НФ, и все неключевые атрибуты зависят только от первичного ключа (нет транзитивных зависимостей).
В нашей таблице:
Первичный ключ составной:
(order_id, product_id)customer_idcustomer_nameorder_dateorder_idproduct_idproduct_priceproduct_idЭто частичные зависимости – нарушение 2НФ.
Как исправить?
Разделить на три таблицы:
Orders (order_id, customer_id, order_date)Customers (customer_id, customer_name)OrderItems (order_id, product_id, quantity)Products (product_id, product_price)Реальный кейс:
В старой учётной системе были проблемы с дублированием имён клиентов и цен товаров. После нормализации до 3НФ избыточность снизилась на 70%, а обновление имени клиента перестало требовать правки тысяч записей.
Вывод: Аналитик, проектируя схему БД, должен проверять составные ключи на наличие частичных зависимостей (2НФ) и транзитивных зависимостей (3НФ).
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4875. Устаревший монолит нужно постепенно заменять на микросервисы без остановки системы. Какой паттерн позволяет направлять часть запросов на новый функционал, а часть – на старый, постепенно увеличивая долю нового?
Anonymous Quiz
50%
Strangler Fig (паттерн «душитель»)
21%
Circuit Breaker
14%
Sidecar
14%
Saga
Название происходит от фикуса-душителя, который обвивает дерево-хозяина и постепенно его заменяет. В архитектуре – это стратегия постепенной замены старой системы новой без «большого взрыва» (big bang). На начальном этапе создаётся фасад (прокси, API Gateway), который маршрутизирует запросы: часть отправляется в старый монолит, часть – в новый микросервис. Постепенно функционал переносится, и доля запросов к старой системе уменьшается. В конце концов монолит отключается.
Как это работает на практике:
Создаётся маршрутизатор (Nginx, Zuul, Envoy).
Выделяется первый модуль монолита (например, «каталог товаров») и реализуется как отдельный микросервис.
В маршрутизаторе настраивается правило: запросы к
/catalog/*Следующий модуль («корзина») выделяется аналогично.
Постепенно все маршруты переключаются.
Когда трафик на монолит падает до нуля, он отключается.
Преимущества:
Нет даунтайма.
Возможность отката (при проблемах с новым сервисом можно быстро переключить маршрут обратно).
Каждый этап даёт бизнес-ценность независимо.
Реальный кейс: Amazon переписывал свою архитектуру несколько лет по паттерну Strangler Fig. Каждый микросервис вырезался из монолита и запускался в отдельное окружение. В итоге монолит исчез без единой остановки сервиса.
Что должен зафиксировать аналитик:
Требование: «Замена функциональных модулей должна происходить итеративно, с сохранением работоспособности системы на каждом этапе».
План маршрутизации (какие URL идут на новый сервис).
Критерии переключения (например, когда новый сервис прошёл нагрузочное тестирование).
Вывод: Strangler Fig – стандартный паттерн для безопасного рефакторинга больших систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
4876. Социальная сеть должна быстро находить друзей друзей (path length 2) и общие интересы. Реляционная БД с JOIN-ами работает медленно. Какой тип NoSQL базы данных оптимален для хранения связей и быстрого обхода графа?
Anonymous Quiz
16%
Документо-ориентированная (MongoDB)
20%
Документо-ориентированная (MongoDB)
14%
Документо-ориентированная (MongoDB)
49%
Колоночная (Cassandra)
🤔11🫡4👏3
В социальных сетях запрос «друзья друзей» требует трёх
JOINЧто такое графовая БД?
В графовой БД данные хранятся как вершины (пользователи, интересы, посты) и рёбра (дружба, лайк, подписка). Обход графа происходит через обход смежных вершин, что на порядки быстрее
JOINcypher
MATCH (u:User {id: 123})-[:FRIEND]->(friend)-[:FRIEND]->(friendOfFriend)
RETURN friendOfFriendЭтот запрос выполняется за миллисекунды на графах с миллиардами рёбер.
Почему не подходят другие NoSQL:
Документо-ориентированные (MongoDB) – хранят вложенные структуры, но не оптимизированы для связей произвольной глубины.
Ключ-значение (Redis) – хорош для кэша, но не для сложных запросов к связям.
Колоночные (Cassandra) – для аналитики и временных рядов, не для графов.
Реальный кейс: LinkedIn использует графовую БД для рекомендаций «люди, которых вы можете знать». Facebook хранит социальный граф в TAO (своя графовая БД). В компаниях с большими графовыми данными производительность после перехода с реляционной БД на графовую вырастает в 10–100 раз.
Что должен зафиксировать аналитик:
Требование: «Для хранения социального графа и быстрых запросов на обход связей использовать графовую БД (Neo4j, Neptune, JanusGraph)».
Типичные запросы: поиск друзей друзей, рекомендации по общим интересам, проверка связей на расстоянии до 3.
Вывод: Графовые БД – лучший выбор для сильно связных данных, где важна скорость обхода отношений.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4877. Заказчик требует 20 фич в релизе, но команда понимает, что сделать всё невозможно за отведённое время. Какой метод приоритизации поможет выделить обязательный минимум и договориться о сокращении объёма?
Anonymous Quiz
14%
WSJF (Weighted Shortest Job First)
82%
MoSCoW (Must, Should, Could, Won’t)
0%
Карточки с голосованием
4%
Оценка в story points