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

Что такое token bucket?
Это алгоритм, который контролирует скорость отправки запросов:
Корзина с токенами (например, 10 токенов).
Каждый запрос забирает 1 токен.
Корзина пополняется с заданной скоростью (например, 1 токен в 0.1 секунды).
Если токенов нет, запрос задерживается или отклоняется.

Leaky bucket — аналогичен, но ограничивает не пиковую скорость, а среднюю.

Почему это должен делать клиент?
Если клиент превышает лимиты API, он получит HTTP 429 («Too Many Requests») и может быть заблокирован. Клиент сам должен ограничивать свою нагрузку, чтобы не перегружать внешний сервис и не терять запросы.

Реальный пример
Twitter API ограничивает 300 запросов на 15 минут. Клиентские библиотеки (например, Tweepy) содержат встроенный token bucket. Без него приложение поймает 429 и упадёт.

Что должен зафиксировать аналитик
Требование: «На стороне клиента реализовать ограничение частоты запросов в соответствии со спецификацией API (token bucket)».
Параметры: максимальная скорость, размер корзины, стратегия при переполнении (блокировка, очередь).
Обработка ошибок 429: увеличение задержки (exponential backoff).

Вывод: Rate limiting — обязанность не только провайдера API, но и клиента. Аналитик должен включать это требование в спецификации интеграций.

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

«Импортировать Excel» — функциональное требование, но без брейкдауна (декомпозиции) нельзя спроектировать решение. Аналитик обязан разбить на подвопросы:

Максимальный размер файла: 1 МБ или 2 ГБ? Это влияет на потоковую обработку (chunked) vs загрузка в память.
Форматы: .xlsx, .xls, .csv? Разные парсеры.
Скорость: импорт за 5 секунд или 5 минут?
Обработка ошибок: при неверной строке — откат всего импорта или пропуск с логом?
Многопоточность: можно ли обрабатывать несколько файлов параллельно?

Реальный кейс: Один аналитик не спросил про размер, разработчик загружал файл целиком в память. При 500 МБ сервер упал с OOM. Переделали на потоковый импорт.

Вывод: Любое общее требование должно быть разбито на проверяемые компоненты. Это ключевая техника системного анализа.

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

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% дублей заказов. Отчётность встала на неделю.