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

Webhook — это механизм, при котором внешний сервис сам отправляет HTTP-запрос на ваш endpoint в момент наступления события. Задержка минимальна (секунды). Polling — ваша система постоянно опрашивает сервис «есть ли новости?». Если опрашивать часто, растёт нагрузка; если редко — растёт задержка. Очередь с периодическим чтением тоже вносит задержку. Email — ещё медленнее. В задаче дано: внешний сервис может задерживать отправку до 5 минут, но внутри этого окна webhook — самый быстрый способ.

Реальный пример: Платёжные системы (Stripe, PayPal) используют webhook для оповещения о статусе платежа. Ваш сервер получает уведомление через секунды после оплаты, а не через минуты при polling.

Вывод: Если внешний сервис поддерживает webhook, это лучший вариант для получения событий в реальном времени. Аналитик должен уметь сравнивать webhook и polling в требованиях к интеграции.

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

В реляционной БД для товаров с разным набором атрибутов пришлось бы использовать либо много колонок с NULL (жестко и негибко), либо EAV-модель (таблица «сущность-атрибут-значение»). EAV приводит к сложным запросам с множеством JOIN, падению производительности и нечитаемости. Документоориентированные БД (MongoDB, Couchbase) хранят каждый товар как отдельный JSON-документ, где атрибуты просто поля документа. Схема гибкая, можно добавлять новые атрибуты без миграций. Это идеально для каталогов, CMS, лидов в CRM.

Реальный пример: Интернет-магазины электроники используют MongoDB для каталога, чтобы легко добавлять новые характеристики (например, «наличие eSIM») без изменения схемы.

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

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

Слово «очень быстро» субъективно. Для одного заказчика 2 секунды — отлично, для другого — неприемлемо. Аналитик обязан перевести неопределённое пожелание в измеримые критерии. Например:

«95% запросов на создание заказа должны выполняться не более 500 мс при нагрузке 1000 RPS».

Без цифр разработчик ориентируется на свой опыт, тестировщик не может проверить, а на приёмке начинаются споры. Хороший аналитик задаёт уточняющие вопросы:

Какое максимальное время допустимо?
Какой процент запросов должен укладываться в это время (процентиль)?
При какой нагрузке?

Реальный кейс: В одном проекте «быстрая выгрузка отчёта» означала для заказчика 10 секунд, а разработчик сделал 2 минуты (думая, что это быстро). После внедрения конкретных цифр время сократили до 5 секунд, и заказчик принял работу.

Вывод: Любое расплывчатое требование о качестве (быстрота, надёжность, удобство) нужно превращать в числовые метрики. Это экономит часы споров и переделок.

Вы ведь уже задумывались о заработке в Telegram…

Сохраняли посты.
Читали советы.
Откладывали «на потом».

И вроде бы интерес есть…
но до действий так и не доходит.

Мозг выбирает самое простое — ничего не делать 👉 https://t.me/addlist/BHoA9CZmCi5lM2Yy

Чтобы разорвать этот круг, не нужно сразу «делать идеально».
Достаточно просто дать себе понятную точку входа.

Мы собрали папку, где уже есть база:
— как расти в Telegram
— как привлекать людей
— как выстраивать систему
— как приходить к доходу

Подпишись и просто начни с малого
https://t.me/addlist/BHoA9CZmCi5lM2Yy

Иногда самое сложное — это первый шаг.

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

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

ETL-процессы часто прерываются: сетевой сбой, таймаут, рестарт кластера. Если загрузка не спроектирована идемпотентно, после перезапуска могут появиться дубликаты.

Решение – использовать MERGE (в PostgreSQL) или INSERT ... ON CONFLICT DO UPDATE (в SQLite, PostgreSQL), или REPLACE (MySQL). Уникальный составной ключ (например, order_id + line_id) гарантирует, что повторная вставка не создаст дубль, а обновит существующую строку или проигнорирует её.

Пример кода:
sql

INSERT INTO dwh_orders (order_id, amount, loaded_at)
VALUES (123, 1000, NOW())
ON CONFLICT (order_id) DO UPDATE SET
  amount = EXCLUDED.amount,
  loaded_at = EXCLUDED.loaded_at;

Почему это важно для аналитика?
В требованиях к интеграции данных нужно явно указывать: «Загрузка должна быть идемпотентной. Повторный запуск того же пакета не должен порождать дубликатов». Без этого после каждого сбоя оператору придётся вручную чистить таблицу.
Реальный кейс: В крупном ретейлере из-за отсутствия идемпотентности при ночном сбое накопилось 15% дублей заказов. Отчётность встала на неделю.

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

Функциональные требования описывают что система делает (например, «пользователь может посмотреть баланс»). Нефункциональные требования (NFR) описывают как система это делает (быстро, безопасно, надёжно).
«Открываться за 2 секунды» — это атрибут качества производительности. Это требование не меняет логику работы, а лишь накладывает ограничение на скорость.

Почему это важно?
NFR часто забывают или фиксируют в конце, а потом система работает медленно. Аналитик должен собирать такие требования наравне с функциональными.

Реальный кейс: В одном проекте забыли записать требование к производительности для поиска, и на проде поиск работал 30 секунд. Исправление стоило перепроектирования индексов и кэшей.

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

По умолчанию Kafka сбрасывает данные на диск не сразу, а через интервал (чтобы повысить производительность). При внезапном отключении питания данные, ещё находящиеся в кэше ОС, теряются. Настройка flush.messages=1 заставляет Kafka сбрасывать каждое сообщение на диск перед тем, как подтвердить продюсеру. Недостаток: падает производительность записи.

Альтернатива: использовать репликацию с acks=all и min.insync.replicas=2, но при падении всех брокеров данные могут потеряться, если не сброшены на диск.

Реальный пример: В системе финансового мониторинга настроили персистентность Kafka, и даже при аварийном отключении не потеряли ни одного события.

Что должен зафиксировать аналитик:
Требование к durability (гарантия сохранности) — допускается ли потеря сообщений?
Для критичных логов — обязательная синхронная запись на диск.