☀Объяснение:

Что такое consumer lag (отставание потребителя)?
Это разница между смещением последнего сообщения в очереди и смещением, которое уже обработал потребитель. Если сообщения приходят быстрее, чем обрабатываются, очередь растёт, и задержка доставки (латентность) увеличивается. Например, очередь растёт на 100 сообщений в секунду, через час в ней будет 360 000 необработанных сообщений, а новое сообщение будет ждать обработки часы.

Причины consumer lag:
Медленная бизнес-логика (тяжёлые запросы в БД, вызовы внешних API).
Недостаточное количество потребителей (один consumer на много партиций).
Сетевые задержки или блокировки.

Как решить:
Увеличить количество параллельных потребителей (в RabbitMQ – добавить экземпляры приложения, слушающие ту же очередь; в Kafka – увеличить число consumer’ов в группе, но не больше числа партиций).

Оптимизировать обработку – асинхронные вызовы, пакетная обработка (batch), распараллеливание внутри потребителя.
Использовать flow control – если потребитель не успевает, можно временно приостановить чтение.

Почему не другие варианты:
A (retry storm) – это проблема синхронных ретраев, а не медленного потребителя.
C (deadlock) – взаимоблокировка, не связано с очередью.
D (split brain) – проблема распределённых систем, когда два узла думают, что они лидеры.

Реальный кейс:
В системе логистики потребитель Kafka обрабатывал каждое сообщение (заказ) синхронно, вызывая внешний API доставки (среднее время 200 мс). При пике 5000 сообщений/сек очередь начала расти на 2000 сообщений/сек. Увеличили количество партиций с 1 до 10 и запустили 10 потребителей. Потребление выросло в 10 раз, и отставание прекратилось.

Что должен зафиксировать аналитик:
В требованиях к интеграции указать допустимый consumer lag (например, не более 10 000 сообщений).
Предусмотреть автоматическое масштабирование потребителей (Kubernetes HPA по длине очереди).
Мониторинг: алерт, если lag превышает порог.

Вывод: Consumer lag – главная метрика здоровья систем на основе очередей. Аналитик должен закладывать требования к пропускной способности и мониторингу отставания.

☀Объяснение:

Почему это реальная проблема?
Бизнес-правила, особенно в скоринге или ценообразовании, со временем меняются. Если пороги (50 и 70 баллов) жёстко зашить в код, каждое изменение правила потребует нового релиза, тестирования и развертывания. Это медленно, дорого и рискованно.

Что должен был сделать аналитик:
Выделить варьируемые параметры – в данном случае пороги и, возможно, саму шкалу.
Требовать, чтобы эти параметры хранились во внешней конфигурации (файл, база данных, административная панель) и могли изменяться без перекомпиляции и передеплоя.
Зафиксировать в требованиях механизм динамической настройки – например, «система должна считывать пороги скоринга из таблицы БД при старте и периодически перечитывать их без остановки».

Почему не подходят другие варианты:
A (нагрузочное тестирование) – не связано с изменчивостью правил.
C (согласование с юристами) – полезно, но не решает проблему частых изменений.
D (формальная спецификация) – нужна, но без гибкости всё равно потребуется перекомпиляция.

Реальный кейс:
В одном банке кредитные пороги менялись раз в месяц. Они были закодированы в Java-классах. Каждый раз команда делала релиз (2 дня). После перехода на конфигурационный файл с автоматической перезагрузкой изменения стали занимать 10 минут.
Что должен зафиксировать аналитик (расширенное требование):

«Пороговые значения для принятия решения по скорингу должны быть вынесены во внешний конфигурационный файл или базу данных. Система должна перечитывать их без перезапуска при изменении. Интервал перечитывания – не более 5 минут. Изменение порогов не должно требовать остановки работы системы».

Дополнительные аспекты:
Аудит изменений – кто, когда и почему изменил порог.
Валидация новых порогов (например, нижний порог не может быть выше верхнего).
Возможность A/B-тестирования разных порогов в разных сегментах клиентов.

Вывод: Аналитик обязан выявлять параметры бизнес-правил, которые могут меняться со временем, и закладывать их во внешнюю конфигурацию. Это ускоряет внесение изменений и снижает стоимость доработок.

☀Объяснение:

Нотация UML:
Синхронное сообщение – сплошная стрелка с заполненным треугольником (отправитель ждёт ответа).

Асинхронное сообщение – открытая стрелка (незаполненный треугольник). Отправитель не блокируется.
Ответ (callback) изображается отдельным асинхронным сообщением в обратном направлении (или сплошной стрелкой, если это возврат управления).

Реальный пример: Приложение отправляет запрос на оплату в платёжный шлюз и продолжает показывать анимацию. Через некоторое время шлюз присылает результат на webhook – это отдельное асинхронное сообщение.

Ошибка: Если нарисовать синхронную стрелку, подразумевается блокировка, что не соответствует реальности.

Вывод: Аналитик, моделируя интеграции, должен различать синхронные и асинхронные вызовы на диаграммах последовательности.

Хочешь зарабатывать в Telegram, но канал стоит на месте?

Скорее всего, ты просто делаешь всё «наугад».

❌ системы.
❌ понимания.
❌ результата.

Мне постоянно пишут:

✅«Почему не идут подписчики?»
✅«Почему нет продаж?»
✅«Что я делаю не так?»

Ответ почти всегда один — у тебя нет базы.

Не хватает понимания маркетинга, продвижения и логики заработка в Telegram.

И именно поэтому я собрала папку, где уже есть всё необходимое:

— как расти в Telegram
— где брать трафик
— как превращать подписчиков в деньги
— как выстроить систему, а не надеяться на «повезёт»

Ссылка: https://t.me/addlist/sieqVFdCuh5iZWIy

Записывайся в подборку🫶

☀Объяснение:

Оконная функция LAG() позволяет получить предыдущее значение в отсортированном наборе. Если order_number - LAG(order_number) > 1, значит есть пропуск между предыдущим и текущим номером.
Пример запроса:
sql

WITH gaps AS (
    SELECT 
        LAG(order_number) OVER (ORDER BY order_number) AS prev_num,
        order_number AS curr_num
    FROM orders
)
SELECT (prev_num + 1) AS missing_start, (curr_num - 1) AS missing_end
FROM gaps
WHERE curr_num - prev_num > 1;

Почему другие варианты хуже:

B (LEFT JOIN с таблицей всех чисел) – требует генерации последовательности, что при больших диапазонах неэффективно.
C (GROUP BY) – не может найти пропуски без генерации всех значений.
D (NOT EXISTS) – потребует для каждого номера подзапрос, что медленно.

Реальный кейс: В интернет-магазине из-за ошибок в интеграции номера заказов иногда пропускались. Аналитик написал запрос с LAG() и за 0.1 секунды нашёл все разрывы в таблице из 10 млн записей.

Вывод: LAG() – оптимальный инструмент для поиска пропусков в последовательностях без генерации вспомогательных таблиц.

☀Объяснение:

Когда за сайтом стоит несколько серверов (кластер), балансировщик распределяет запросы между ними. Если балансировщик отправляет каждый запрос на случайный сервер (round robin), то данные сессии (корзина, авторизация) могут храниться на одном сервере, а следующий запрос попадёт на другой, где этих данных нет. Пользователь «теряет» корзину или его выкидывает из системы.

Что такое sticky sessions (сессионная аффинность)?
Балансировщик «привязывает» пользователя к определённому серверу на время его сессии. Обычно это делается:
По IP-адресу (не очень надёжно, так как несколько пользователей могут быть за одним NAT).
По cookie, которую балансировщик устанавливает клиенту (более надёжно).
Все последующие запросы этого пользователя направляются на тот же сервер, где хранятся его сессионные данные.

Почему не подходят другие варианты:
B (round robin) – как раз вызывает проблему, так как запросы распределяются по очереди без учёта сессии.
C (least connections) – направляет запрос на сервер с наименьшим числом активных соединений, тоже не учитывает сессию.
D (IP hash) – один из способов реализации sticky sessions, но это не общее название механизма, а частная техника. Правильным ответом является именно термин «sticky sessions» (сессионная аффинность).

Реальный пример:
В интернет-магазине на платформе Magento с несколькими бэкенд-серверами не настроили sticky sessions. Пользователи жаловались, что корзина очищается при переходе на страницу оформления заказа. После включения sticky sessions на балансировщике (HAProxy) проблема исчезла.

Что должен зафиксировать аналитик:
В требованиях к отказоустойчивости и масштабированию указать необходимость поддержки сессионной аффинности.
Уточнить, где хранить сессии (в памяти сервера, в Redis, в БД).
Если используется Redis для централизованного хранения сессий, sticky sessions не нужны, но требуется надёжный Redis-кластер.

Вывод: Sticky sessions — простой способ решить проблему «потери» сессии при масштабировании, но он создаёт свою проблему: при отказе сервера пользователь теряет сессию. Более современный подход — централизованное хранилище сессий (Redis) и отказ от липких сессий. Аналитик должен понимать оба варианта и выбирать под требования.

☀Объяснение:

Graceful degradation – это способность системы сохранять основную функциональность при отказе второстепенных компонентов. В примере основной функционал – просмотр фильма. Рекомендации – дополнительная функция, но из-за синхронного вызова их падение блокирует плеер.

Как правильно:
Разделить критический и не критический функционал.
При ошибке рекомендаций показывать пользователю плеер, а рекомендации загружать асинхронно (или не показывать вовсе).
Использовать таймауты и fallback-значения.

Реальный кейс: В Netflix при падении сервиса рекомендаций пользователь всё равно может смотреть фильм. Это достигается за счёт асинхронных вызовов и fallback.

Вывод: Аналитик должен закладывать в требования graceful degradation: «При недоступности модуля рекомендаций плеер должен работать, а рекомендации не должны блокировать показ».