4786. Нужно найти клиентов, у которых сумма покупок за всё время превышает 1 000 000 рублей. Какой запрос правильный?
Anonymous Quiz
15%
SELECT client_id FROM sales WHERE SUM(amount) > 1000000
55%
SELECT client_id FROM sales GROUP BY client_id HAVING SUM(amount) > 1000000
17%
SELECT client_id, SUM(amount) > 1000000 FROM sales GROUP BY client_id
13%
SELECT client_id FROM sales GROUP BY client_id WHERE SUM(amount) > 1000000
Нужно отфильтровать сгруппированные данные по агрегатной функции (SUM). WHERE применяется до группировки и не может использовать агрегаты. HAVING — после группировки и предназначен именно для фильтрации групп.
Разбор вариантов:
A (WHERE SUM(...)) — синтаксическая ошибка, WHERE не видит агрегат.
B — корректно: сначала группируем по client_id, считаем сумму, потом оставляем только те группы, где сумма > 1 000 000.
C — вернёт для каждого клиента булево значение, но не отфильтрует строки.
D — WHERE нельзя использовать после GROUP BY (порядок: WHERE → GROUP BY → HAVING).
Реальный кейс:
В аналитике продаж часто спрашивают: «Покажи клиентов, купивших больше чем на N рублей». Новички пишут WHERE SUM(amount) > N и получают ошибку. Правильный запрос с HAVING выполняется мгновенно, если есть индекс на client_id.
Вывод для аналитика:
WHERE — фильтрует строки до группировки.
HAVING — фильтрует группы после агрегации.
Запомните порядок: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY.
Please open Telegram to view this post
VIEW IN TELEGRAM
ПОДПИСКИ НА ИИ-КАНАЛЫ ЕСТЬ, А СВЕЖИХ ИДЕЙ — НОЛЬ !?
* Твои подписки устарели (outdated). Пора сделать АПГРЕЙД своего информационного поля.
Сегодняшний ИИ — это не «10 крутых промтов» и не новость про ChatGPT-5. Это рабочие связки, реальные кейсы, свежие инструменты, которые сэкономят тебе часы уже на этой неделе.
Проблема не в том, что ты мало читаешь. А в том, что ты читаешь не тех ...
Мы собрали свежую ПОДБОРКУ каналов, где авторы реально работают с технологиями здесь и сейчас. Никаких повторов и воды. Только практика, кейсы, новые тулы и разборы, которые имеют значение.
📂 Добавляй ПАПКУ — и получи полный АПГРЕЙД своей ленты:
➡️ https://t.me/addlist/r5VfG-YYZB9mNzM8
* Сделай свою подписку умнее, пока другие читают вчерашние новости и не бойся перемен ...
Отписаться можно в любой момент. Остаться — тоже ✔️
* Твои подписки устарели (outdated). Пора сделать АПГРЕЙД своего информационного поля.
Сегодняшний ИИ — это не «10 крутых промтов» и не новость про ChatGPT-5. Это рабочие связки, реальные кейсы, свежие инструменты, которые сэкономят тебе часы уже на этой неделе.
Проблема не в том, что ты мало читаешь. А в том, что ты читаешь не тех ...
Мы собрали свежую ПОДБОРКУ каналов, где авторы реально работают с технологиями здесь и сейчас. Никаких повторов и воды. Только практика, кейсы, новые тулы и разборы, которые имеют значение.
📂 Добавляй ПАПКУ — и получи полный АПГРЕЙД своей ленты:
➡️ https://t.me/addlist/r5VfG-YYZB9mNzM8
* Сделай свою подписку умнее, пока другие читают вчерашние новости и не бойся перемен ...
Отписаться можно в любой момент. Остаться — тоже ✔️
🔥1
ХОЧЕШЬ ИДТИ В НОГУ С ТЕХНОЛОГИЯМИ ?! … или наблюдать, как другие зарабатывают на ИИ? - РЕШАТЬ ТЕБЕ !
ИИ станет твоим главным инструментом, а не загадкой 🗝
Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️
Что внутри? Только лучшее из Мира IT & AI :
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
Делимся знаниями и аудиторией - растём вместе ⚡️ Забирай бесплатно ПАПКУ с ТОП ИИ Каналами
Твой доступ к подборке и бонусам:
➡️ Просто добавь Папку - никаких смс или регистраций. Отписаться можно в любой момент. Остаться — тоже ✔️ * Ссылка - https://t.me/addlist/r5VfG-YYZB9mNzM8
ИИ станет твоим главным инструментом, а не загадкой 🗝
Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️
Что внутри? Только лучшее из Мира IT & AI :
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
Делимся знаниями и аудиторией - растём вместе ⚡️ Забирай бесплатно ПАПКУ с ТОП ИИ Каналами
Твой доступ к подборке и бонусам:
➡️ Просто добавь Папку - никаких смс или регистраций. Отписаться можно в любой момент. Остаться — тоже ✔️ * Ссылка - https://t.me/addlist/r5VfG-YYZB9mNzM8
🔥2❤1👍1
4787. Платёжный шлюз иногда присылает повторный callback об успешной оплате. Из-за этого деньги списываются дважды. Какое требование нужно добавить в интеграцию?
Anonymous Quiz
1%
Увеличить таймаут ожидания callback
98%
Идемпотентность обработки: проверять уникальный идентификатор платежа перед списанием
1%
Отключить повторные callback на стороне шлюза
0%
Добавить ручное подтверждение оператором каждого платежа
Платёжные системы часто работают по протоколу at‑least‑once (гарантия доставки, но с возможными дублями). Сетевые сбои, перезапуски сервисов, таймауты могут привести к тому, что один и тот же успешный платёж уведомит ваш сервис дважды. Если ваша система просто списывает деньги по каждому вызову, клиент заплатит дважды. Скандал, возвраты, штрафы.
Решение — идемпотентность:
Обработчик платежа должен быть спроектирован так, чтобы повторная обработка того же платежа не меняла состояние системы (не списывала деньги повторно, не создавала дубликат заказа). Для этого нужно:
Каждому платежу присвоить уникальный идентификатор (например, payment_id).
При получении callback проверить, не обрабатывался ли уже этот payment_id.
Если обрабатывался — просто вернуть успех, ничего не делая.
Если нет — выполнить списание и запомнить payment_id в БД или кэше.
Пример кода (вариант B):
```python
def payment_callback(payment_id, amount):
# Ключ идемпотентности — payment_id
if redis.exists(payment_id):
return {"status": "already_processed"}
# Блокируем ключ на время обработки (например, 24 часа)
redis.setex(payment_id, 86400, "processed")
# Выполняем списание (только один раз)
debit_account(amount)
return {"status": "success"}
```
❌ Почему не другие варианты:
A (увеличить таймаут) — не решит проблему дублей, таймаут относится к ожиданию ответа, а не к повторным вызовам.
C (отключить повторные callback) — невозможно, внешний шлюз не позволит, да и это снизит надёжность (при сбое уведомление не придёт вообще).
D (ручное подтверждение) — убивает автоматизацию, требует персонала, не масштабируется.
Реальный кейс:
Интернет-магазин подключил платёжный агрегатор. В первые же дни у нескольких клиентов списалось вдвое больше. Причина — агрегатор в целях надёжности дублировал callback при таймауте подтверждения (магазин отвечал чуть дольше 3 секунд). После внедрения проверки по payment_id дубликаты перестали наносить урон.
Вывод для аналитика:
Идемпотентность — обязательное требование для интеграций с внешними системами, которые могут вызывать один и тот же коллбек несколько раз (а это почти все платёжные, SMS, email, push-сервисы). Аналитик должен явно прописывать в требованиях: «Обработчик должен быть идемпотентным, используя уникальный идентификатор события». 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы уже выбрали где будете продвигаться в 2026 году ?
Все разделись на разные лагеря, кто-то:
— Продвигает Телеграм
— Уходит в Мах
— Развивает ВК и Нельзяграм, и другие площадки
Кто бы что не говорил, но наступает эра многоканальности и важно не расслабляться!
Поэтому мы с коллегами для вас подготовили в закрытом канале готовые инструкции по продвижению🚀
Что вас ждет?
• Как набрать первую 1000 подписчиков в Telegram бесплатно
• Жирная статья «30 актуальных способов трафика в Телеграм»
• Как бесплатно привлекать подписчиков из Threads и получать заявки системно
• АВИТО: Как найти рабочую связку за 15000р
• Как получать заявки из Pinterest
• Как набрать подписчиков в свой блог в Дзене
• Секретные связки, которые обеспечивают поток заявок за 7 дней
• База проверенных блогеров для рекламы в тг
• Простые инструменты ИИ для ускорения работы и генерации лидов
• Шаблоны сообщений для закрытия клиентов на продажу по переписке
• Схема продаж на холодную аудиторию
• Примеры лидмагнитов, которые продают за вас
• Фишки в продвижении во ВКонтакте
• Движуха в МАХ, где можно набрать подписчиков бесплатно!
• Подборка сервисов по поиску каналов для рекламы в МАХ
И многое другое!
Чек-листы, полезные статьи, уроки, подкасты - как находить клиентов в новых реалиях и не сливать бюджет на рекламу впустую!
👇👇👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
Все разделись на разные лагеря, кто-то:
— Продвигает Телеграм
— Уходит в Мах
— Развивает ВК и Нельзяграм, и другие площадки
Кто бы что не говорил, но наступает эра многоканальности и важно не расслабляться!
Поэтому мы с коллегами для вас подготовили в закрытом канале готовые инструкции по продвижению
Что вас ждет?
• Как набрать первую 1000 подписчиков в Telegram бесплатно
• Жирная статья «30 актуальных способов трафика в Телеграм»
• Как бесплатно привлекать подписчиков из Threads и получать заявки системно
• АВИТО: Как найти рабочую связку за 15000р
• Как получать заявки из Pinterest
• Как набрать подписчиков в свой блог в Дзене
• Секретные связки, которые обеспечивают поток заявок за 7 дней
• База проверенных блогеров для рекламы в тг
• Простые инструменты ИИ для ускорения работы и генерации лидов
• Шаблоны сообщений для закрытия клиентов на продажу по переписке
• Схема продаж на холодную аудиторию
• Примеры лидмагнитов, которые продают за вас
• Фишки в продвижении во ВКонтакте
• Движуха в МАХ, где можно набрать подписчиков бесплатно!
• Подборка сервисов по поиску каналов для рекламы в МАХ
И многое другое!
Чек-листы, полезные статьи, уроки, подкасты - как находить клиентов в новых реалиях и не сливать бюджет на рекламу впустую!
Чтобы получить доступ к материалам:
1. Подпишитесь на всех экспертов из папки
2. Перейдите в закрытый канал с названием «ПОДАРКИ»
👇👇👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
Please open Telegram to view this post
VIEW IN TELEGRAM
4788. При моделировании процесса выдачи кредита аналитик использовал два параллельных блока проверки: скоринг и проверку кредитной истории. Заявка отправляется на следующий шаг.
Anonymous Quiz
10%
XOR-шлюз
80%
AND-шлюз (fork + join)
3%
OR-шлюз
7%
Event-шлюз
Самый недооценённый навык сейчас —
умение правильно ставить задачи ИИ.
Можно дать один и тот же запрос -
и получить либо «воду»,
либо результат, который экономит часы работы.
ИИ — это про мышление
Я собрал папку с теми, кто реально умеет с этим работать — иногда захожу, чтобы держать уровень.
https://t.me/addlist/apNCMgFIc6g2NjVi
Вы как используете ИИ: поиграться или уже в работе?
умение правильно ставить задачи ИИ.
Можно дать один и тот же запрос -
и получить либо «воду»,
либо результат, который экономит часы работы.
И дело не в инструменте.
А в том, как ты формулируешь.
Чем точнее вопрос — тем сильнее результат.
ИИ — это про мышление
Я собрал папку с теми, кто реально умеет с этим работать — иногда захожу, чтобы держать уровень.
https://t.me/addlist/apNCMgFIc6g2NjVi
Вы как используете ИИ: поиграться или уже в работе?
Две независимые проверки (скоринг и кредитная история) должны выполняться параллельно. Процесс может идти дальше только после того, как обе проверки завершены. Это классический случай fork/join.
Как это выглядит в BPMN:
Fork (AND-шлюз с одним входом и несколькими выходами) — разделяет поток на две параллельные ветки.
Join (AND-шлюз с несколькими входами и одним выходом) — ждёт завершения всех входящих веток, прежде чем продолжить.
Почему не подходят другие шлюзы:
A (XOR) — выбирает только один путь из нескольких. Не подходит, так как нужны обе проверки.
C (OR) — активирует один или несколько путей. Но слияние OR может продолжаться после завершения любой из веток, что не гарантирует выполнение обеих.
D (Event) — выбирает путь на основе наступления события (таймер, сообщение), не подходит для параллельных задач.
Реальный кейс:
В банке процесс выдачи кредита изначально был последовательным: сначала скоринг, потом кредитная история. Время ожидания — 2 минуты. Аналитик перерисовал процесс с AND-шлюзом, и проверки стали выполняться параллельно. Время сократилось до 1 минуты. Экономия времени клиентов — 50%.
Что должен зафиксировать аналитик:
Если задачи не зависят друг от друга и могут выполняться одновременно — используйте AND-шлюз.
Не забывайте про join, иначе процесс «зависнет» в нескольких параллельных потоках.
В спецификации к каждой ветке укажите, какие данные нужны для следующего шага.
Вывод: AND-шлюз — ключевой элемент для параллельного выполнения независимых задач. Аналитик, умеющий применять fork/join, оптимизирует время протекания процесса (cycle time).
Please open Telegram to view this post
VIEW IN TELEGRAM
Подарки от маркетологов, которые заменят десятки курсов!
🎁 Чек-листы, инструкции, воронки, скрипты —
всё, что можно взять и сразу применить в реальной практике:
— привлечь клиентов уже за первую неделю
— выстроить стабильный поток заявок
— быстрее найти работающие связки в разных соц.сетях ( Телеграм, МАХ, ВКонтакте, Авито, Дзен, Нельзяграм, Тредс, Pinterest)
Подпишись на подборку и получи доступ к материалам👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
🎁 Чек-листы, инструкции, воронки, скрипты —
всё, что можно взять и сразу применить в реальной практике:
— привлечь клиентов уже за первую неделю
— выстроить стабильный поток заявок
— быстрее найти работающие связки в разных соц.сетях ( Телеграм, МАХ, ВКонтакте, Авито, Дзен, Нельзяграм, Тредс, Pinterest)
Подпишись на подборку и получи доступ к материалам👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
4789. Компания обновила REST API, добавив обязательное поле в запрос. Старые клиенты сломались. Какой подход предотвратил бы поломку?
Anonymous Quiz
22%
Версионирование через параметр запроса ?version=1
4%
Версионирование через заголовок Accept
40%
Поддержка нескольких версий API одновременно с grace period
34%
Версионирование через путь /v1/resource
API эволюционирует: бизнес требует новых полей, меняется логика. Если сразу удалить старый контракт, все существующие клиенты (ваши мобильные приложения, интеграции партнёров) перестанут работать. Это называется breaking change (ломающее изменение). Клиенты не обновляются мгновенно — некоторые могут использовать старую версию годами.
Почему C — правильный?
Поддержка нескольких версий означает, что и старый, и новый API продолжают работать параллельно.
Grace period (период мягкого перехода) — объявляется дата, когда старая версия перестанет поддерживаться (например, через 6 месяцев). Клиенты получают предупреждение (deprecation warning) в заголовках ответа.
За это время все клиенты мигрируют на новую версию. Только потом старую версию можно отключать.
❌ Почему не подходят другие варианты?
A, B, D — способы указать версию (через URL, параметр или заголовок). Это важно, но не решает главное: если вы перестали принимать старый формат, никакое версионирование не спасёт. Нужно одновременно обслуживать обе версии.
Ключевое требование — не «как указать версию», а «обеспечить совместимость на период миграции».
Как это выглядит в требованиях аналитика:
API должен поддерживать версионность через URL /v1/... и /v2/....
При введении новой версии старая должна поддерживаться минимум 6 месяцев.
В ответах старой версии должен присутствовать заголовок Deprecation: true и ссылка на документацию новой версии.
Изменения не должны ломать существующих клиентов без предупреждения (no breaking changes без deprecation policy).
Реальный кейс:
Платёжный шлюз изменил формат ответа: заменил поле amount на amount_cents. Не оставив старый вариант. Партнёры, использовавшие старое поле, перестали получать суммы. Инцидент стоил миллионы потерянных транзакций. После этого ввели правило: любые изменения — только с новой версией API, а старую поддерживать 1 год.
Что должен зафиксировать аналитик:
Политику версионирования (URL, заголовок, параметр — выбрать один).
Срок поддержки устаревшей версии (например, 6–12 месяцев).
Механизм уведомления о депрекации (заголовки, письма партнёрам).
Набор тестов на совместимость (старые клиенты продолжают работать после обновления).
Вывод: Версионирование API — это не только технический механизм, но и процесс управления изменениями. Аналитик обязан описать политику депрекации и grace period, иначе каждый релиз API будет приносить падения на проде. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
4790. Сервис доставки упал, заказы продолжают создаваться, но уведомления не отправляются. Какой паттерн изолирует сбой и сохранит уведомления?
Anonymous Quiz
5%
Общий кэш Redis
7%
Синхронные REST с ретраями
88%
Асинхронная очередь + Dead Letter Queue
0%
Общая база данных
Асинхронная очередь сообщений (RabbitMQ, Kafka, SQS) выступает буфером. Сервис-источник (заказы) публикует события и не ждёт ответа. Сервисы-потребители (доставка, уведомления) читают из очереди в своём темпе. Если потребитель упал, сообщения накапливаются — они не теряются, а дожидаются восстановления.
Dead Letter Queue (DLQ) — дополнительная защита:
Сообщения, которые не удалось обработать после нескольких попыток (например, из-за ошибки в данных или долгого сбоя), перемещаются в DLQ. Оттуда их можно анализировать, исправлять и повторно отправлять. Это предотвращает «зависание» основной очереди и потерю данных.
❌ Почему остальные варианты не подходят:
A (общий кэш) — не решает проблему доставки и уведомлений.
B (синхронные REST) — даже с ретраями при длительном падении сервиса доставки потоки исчерпаются, заказы заблокируются, уведомления потеряются.
D (общая БД) — создаёт жёсткую связь, ведёт к монолиту, а сбой одного сервиса может заблокировать таблицы и уронить всю систему.
Реальный кейс:
В сервисе такси при звоне водителя использовался синхронный вызов к API поиска ближайших машин. При его падении заказы переставали создаваться. Перешли на Kafka: водитель отправляет событие «хочу заказ», система отвечает мгновенно, а подбор машин идёт асинхронно. При падении подборщика заказы копятся в очереди, водители не теряются. DLQ ловит сообщения с некорректными координатами для ручного разбора.
Что аналитик должен зафиксировать в требованиях:
Для всех взаимодействий, не требующих немедленного ответа, использовать асинхронную очередь.
Настроить Dead Letter Queue с количеством повторных попыток (например, 3) и экспоненциальной задержкой.
Обеспечить мониторинг длины очереди и количества сообщений в DLQ.
Потребители должны быть идемпотентными.
Вывод: Асинхронная очередь с DLQ — золотой стандарт для построения устойчивых микросервисных систем. Аналитик, закладывающий эти паттерны, предотвращает каскадные отказы и потерю критичных бизнес-событий. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM