Способы версионирования:
Через URL (
/v1/customers/v2/customersЧерез параметр запроса (
?version=2Через заголовок Accept – стандартный способ для REST, основанный на медиатипах. Клиент указывает желаемую версию в заголовке, например:
Accept: application/vnd.myapi.v2+jsonПочему B – правильный ответ:
Использование
AcceptНе засоряет URL, сохраняет единый endpoint.
Позволяет гибко комбинировать версию и формат (JSON, XML).
Сравнение с другими вариантами:
A (параметр
?versionC (разные URL) – классический подход, но вопрос явно описывает заголовок как способ указать версию.
D (тело запроса) – нестандартно, требует разбора тела до того, как будет понята версия (курица-яйцо).
Реальный пример:
GitHub API версионирует через заголовок
Accept: application/vnd.github.v3+jsonЧто должен зафиксировать аналитик:
В требованиях указать, что API поддерживает версионирование через заголовок
AcceptДокументировать возможные значения (v1, v2, latest).
Определить политику депрекации старых версий.
Вывод: Версионирование через заголовок
AcceptPlease open Telegram to view this post
VIEW IN TELEGRAM
4893. В таблице counters есть поле value. Два параллельных запроса могут прочитать одно и то же значение, увеличить и записать, что приведёт к потере одного инкремента. Какая SQL-конструкция гарантирует атомарное увеличение без блокировок на чтение?
Anonymous Quiz
14%
SELECT value FROM counters WHERE id = 1; UPDATE counters SET value = value + 1 WHERE id = 1;
35%
UPDATE counters SET value = value + 1 WHERE id = 1 (один запрос)
37%
BEGIN; SELECT ... FOR UPDATE; UPDATE ...; COMMIT;
15%
INSERT INTO counters (value) VALUES (1) ON DUPLICATE KEY UPDATE value = value + 1
Два процесса одновременно читают
value = 5Решение – атомарный UPDATE:
В большинстве реляционных СУБД (PostgreSQL, MySQL, Oracle) оператор
UPDATE SET value = value + 1Почему не подходят другие варианты:
A (два отдельных запроса) – не атомарно, гонка неизбежна.
C (
SELECT ... FOR UPDATED (UPSERT) – работает, но тяжеловесно, если гарантированно существует запись.
Важно для аналитика:
Если нужен атомарный инкремент – используйте один UPDATE.
Если нужно прочитать старое значение перед обновлением (например, для логирования), то придётся использовать
SELECT ... FOR UPDATEДля высоконагруженных счётчиков (лайки, просмотры) часто используют Redis (атомарный
INCRРеальный пример:
В счетчике просмотров видео на YouTube используется атомарный UPDATE в базе данных для финальной консистентности, а промежуточные инкременты накапливаются в Redis.
Что должен зафиксировать аналитик:
«При обновлении счётчика использовать атомарный
UPDATE SET field = field + 1Если нужно получить предыдущее значение – оформить требование на пессимистическую блокировку.
Вывод: Простой атомарный UPDATE – самое производительное и надёжное решение для счётчиков без необходимости читать старое значение.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
В этой папке собраны каналы про ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.
Please open Telegram to view this post
VIEW IN TELEGRAM
4894. Команда хочет выкатить новую версию рекомендательного сервиса, но не уверена в её стабильности. Нужно сначала направить на неё 1% трафика, а если ошибок нет – постепенно увеличивать. Какая стратегия деплоя это позволяет?
Anonymous Quiz
16%
Rolling update
48%
Canary deployment
27%
Blue‑Green deployment
10%
Shadow deployment
Название происходит от практики «канарейки в угольной шахте» (раньше шахтёры брали с собой канарейку – если она падала, значит, есть угарный газ). В IT – это стратегия, при которой новая версия приложения сначала получает маленькую долю трафика (например, 1% пользователей или запросов). Затем команда наблюдает за метриками (ошибки, время отклика). Если всё хорошо, доля постепенно увеличивается (5%, 20%, 50%, 100%). Если возникают проблемы, можно быстро откатить, направив 100% трафика на старую версию.
Чем отличается от других стратегий:
A (Rolling update) – постепенная замена подов, но трафик распределяется между старыми и новыми подами, а не контролируется на уровне процентного соотношения.
C (Blue‑Green) – требует двух полных окружений и мгновенного переключения. Не позволяет постепенно наращивать трафик.
D (Shadow deployment) – новая версия получает «теневой» трафик (копию запросов), но не обслуживает реальных пользователей. Хорошо для тестирования под нагрузкой, но не для проверки на реальных пользователях.
Реальный пример:
Netflix, Google, Amazon используют canary deployment для критических сервисов. Например, новая версия поиска сначала обрабатывает 0.5% запросов, а затем, если метрики в норме, долю увеличивают.
Что должен зафиксировать аналитик:
Требование: «Выкатка новых версий должна происходить по стратегии канареечного релиза с возможностью контролировать процент трафика».
Определить ключевые метрики для автоматического отката (например, увеличение ошибок 500 более чем на 0.1%).
Вывод: Canary deployment – идеальный выбор, когда нужно снизить риски, выпуская новую функциональность постепенно.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4895. В CRM нужно реализовать «корзину»: удалённые заказы должны восстанавливаться в течение 30 дней, после чего удаляться навсегда. Как спроектировать хранение удалённых заказов без падения производительности основных запросов?
Anonymous Quiz
38%
Добавить в таблицу orders поле is_deleted (мягкое удаление) с индексом
47%
Создать отдельную таблицу deleted_orders и фоновым процессом переносить туда записи
3%
Удалять заказы сразу физически и хранить резервные копии
11%
Использовать партиционирование по дате удаления
Добавление поля
is_deletedWHERE is_deleted = falseРешение – отдельная архивная таблица (B):
Основная таблица
ordersПри удалении заказ перемещается в таблицу
deleted_ordersФоновый процесс раз в день удаляет из
deleted_ordersВосстановление – перенести строку обратно в
ordersПреимущества:
Основная таблица остаётся маленькой и быстрой.
Архивную таблицу можно хранить на более дешёвом и медленном диске, сжатой.
Простые запросы (
SELECT * FROM ordersis_deletedНедостатки:
Требуется фоновый процесс перемещения данных (можно реализовать через триггер + job).
Если восстанавливать часто, то перемещения туда-обратно могут стать нагрузкой.
Почему не подходят другие варианты:
C (физическое удаление + резервные копии) – восстановление сложно, требует разворачивания бэкапа.
D (партиционирование по дате удаления) – помогает, но не решает проблему накопления «мёртвых» записей в основной таблице.
Реальный пример:
В сервисе управления заказами Ozon удалённые заказы переносятся в отдельную таблицу, и только последние 30 дней хранятся в горячем архиве. Это позволило сократить размер основной таблицы на 70%.
Что должен зафиксировать аналитик:
«Удалённые объекты должны храниться отдельно от активных с автоматической очисткой через 30 дней».
«Фоновый процесс не должен создавать блокировок в основной таблице».
Вывод: Для больших таблиц с функцией восстановления архитектура с отдельной архивной таблицей предпочтительнее мягкого удаления.
Please open Telegram to view this post
VIEW IN TELEGRAM
Сейчас в digital и IT странный момент.
Вроде всё то же самое:
те же инструменты, те же площадки, те же люди. Но результаты — как будто из разных реальностей.
У одних стагнация, у других рост.
И это уже не про «лучше настроили рекламу».
Это про то, как вообще думают и принимают решения. Кто-то продолжает делать по старым схемам и упирается в потолок, а кто-то пересобирает подход и находит деньги там, где их раньше не видел.
Собрали папку по digital и IT как раз про это состояние рынка —
без иллюзий, но с пониманием, куда всё двигается и как под это адаптироваться.
Сохранить папку себе 🗂
Вроде всё то же самое:
те же инструменты, те же площадки, те же люди. Но результаты — как будто из разных реальностей.
У одних стагнация, у других рост.
И это уже не про «лучше настроили рекламу».
Это про то, как вообще думают и принимают решения. Кто-то продолжает делать по старым схемам и упирается в потолок, а кто-то пересобирает подход и находит деньги там, где их раньше не видел.
Собрали папку по digital и IT как раз про это состояние рынка —
без иллюзий, но с пониманием, куда всё двигается и как под это адаптироваться.
Сохранить папку себе 🗂
4896. Платёжный шлюз присылает вебхук на ваш сервер. Если сервер временно недоступен, шлюз не повторяет отправку и вебхук теряется. Как гарантировать доставку, не меняя код шлюза?
Anonymous Quiz
5%
Увеличить количество серверов для высокой доступности
76%
Принимать вебхук на минимальный endpoint, который сразу кладёт сообщение в очередь
18%
Настроить на шлюзе повторные попытки через 5 минут
1%
Хранить вебхуки в локальной базе данных
Внешние системы (платёжные шлюзы, CRM, биллинги) часто имеют простую логику отправки вебхуков: отправили, не получили 200 OK за пару секунд – считают доставку неудачной и не повторяют (или делают 1-2 повтора без возможности настройки). При перезагрузке вашего сервера, деплое новой версии или кратковременной сетевой проблеме вы теряете критическое уведомление (например, об успешной оплате). Увеличить количество серверов (A) не спасёт, если все они заняты или обновляются. Настроить шлюз (C) невозможно – шлюз не даёт такой опции. Локальная БД (D) создаст узкое место и не решит проблему распределённой обработки.
Решение – асинхронный буфер (B):
Вы создаёте публичный endpoint, который делает только минимум:
Проверяет подпись вебхука (безопасность).
Кладёт сырое сообщение в очередь (RabbitMQ, Kafka, SQS).
Отвечает HTTP 200 OK (мгновенно).
Вся остальная логика (парсинг, обновление заказа, запись в БД, отправка уведомлений) выполняется отдельными воркерами, читающими из очереди.
Почему это гарантирует доставку:
Шлюз получает быстрый 200 и считает, что вебхук доставлен.
Очередь хранит сообщения персистентно (на диске, с репликами).
Если воркер упал, сообщение не теряется – оно будет обработано позже.
Очередь позволяет масштабировать обработку (добавлять воркеры) и выдерживать пиковые нагрузки.
Реальный пример:
Stripe, PayPal, GitHub Webhooks рекомендуют именно такой паттерн: endpoint только валидирует и ставит задачу в очередь. Это позволяет переживать простои и деплои без потери данных.
Что должен зафиксировать аналитик:
Требование: «Endpoint приёма вебхуков должен быть неблокирующим: валидация + публикация в очередь + HTTP 200. Основная обработка – асинхронно».
Очередь должна быть персистентной, с политикой повторных попыток.
Мониторинг длины очереди – алерт при накоплении сообщений.
Вывод: Паттерн «вебхук → очередь → воркер» – стандарт для интеграций с внешними системами, где нельзя влиять на логику повторной отправки. Аналитик, закладывающий этот паттерн, обеспечивает отказоустойчивость критических уведомлений.
Please open Telegram to view this post
VIEW IN TELEGRAM
ТЕХНОЛОГИИ ИИ НЕ ЖДУТ! А ты успеваешь делать UPGRADE ?!
* Каждую неделю выходят десятки обновлений нейросетей и новых инструментов. То, что вчера делали за 3 часа, сегодня нейросеть делает за 5 минут. Вопрос только в том — узнаете ли вы об этом первыми?
Пока большинство спит, единицы тестируют новые связки и вырываются вперед. Хотите быть в их числе?
Мы собрали ПОДБОРКУ со всеми свежими ИИ-инструментами, фишками и апдейтами. Никакой воды — только то, что реально упрощает работу и приносит результат.
👉 Делимся знаниями и аудиторией — растём вместе ⚡️
Отписаться можно в любой момент. Остаться — тоже ✔️
Добавляй ПАПКУ в свой актив и делись с друзьями! 📌
* Каждую неделю выходят десятки обновлений нейросетей и новых инструментов. То, что вчера делали за 3 часа, сегодня нейросеть делает за 5 минут. Вопрос только в том — узнаете ли вы об этом первыми?
Пока большинство спит, единицы тестируют новые связки и вырываются вперед. Хотите быть в их числе?
Мы собрали ПОДБОРКУ со всеми свежими ИИ-инструментами, фишками и апдейтами. Никакой воды — только то, что реально упрощает работу и приносит результат.
👉 Делимся знаниями и аудиторией — растём вместе ⚡️
Отписаться можно в любой момент. Остаться — тоже ✔️
Добавляй ПАПКУ в свой актив и делись с друзьями! 📌
👍1
❇️ Gemini — ТВОЙ МОЗГ В ОБЛАКЕ Google ☁️
* Сейчас всё только про ChatGPT, но я перешёл на Gemini и не жалею. Бесплатно (в базе), контекст 2M токенов, нативная мультимодальность — понимает текст, картинки, видео и аудио. Глубокая интеграция с Google Диском, Gmail и календарём. Рассуждает как senior-аналитик, а код пишет не хуже топ-моделей.
Решил протестировать агентский режим на задаче, которую вечно откладывал — собрать чистое инфополе с нуля. Чтобы не перебирать паблики вручную, зашёл через функцию похожих каналов в Telegram.
Скормил Gemini ссылки на качественных авторов по IT и AI, которых читаю сам, и попросил проанализировать сотни рекомендаций. Агент изучил контент на каналах и оставил только тех, кто делится практическим опытом по: AI-воркфлоу, автоматизации, вайб-кодингу, промт-инжинирингу, RAG-системам, нейрогенерации и др.
Gemini собрал полезную ПОДБОРКУ экспертов в одну папку. Делюсь списком — внутри только полезный контент про IT & AI.
🔗 Забирай экспертный СПИСОК в один клик: 👉 https://t.me/addlist/1lX_fOkYZXFmZDhk
* Сейчас всё только про ChatGPT, но я перешёл на Gemini и не жалею. Бесплатно (в базе), контекст 2M токенов, нативная мультимодальность — понимает текст, картинки, видео и аудио. Глубокая интеграция с Google Диском, Gmail и календарём. Рассуждает как senior-аналитик, а код пишет не хуже топ-моделей.
Решил протестировать агентский режим на задаче, которую вечно откладывал — собрать чистое инфополе с нуля. Чтобы не перебирать паблики вручную, зашёл через функцию похожих каналов в Telegram.
Скормил Gemini ссылки на качественных авторов по IT и AI, которых читаю сам, и попросил проанализировать сотни рекомендаций. Агент изучил контент на каналах и оставил только тех, кто делится практическим опытом по: AI-воркфлоу, автоматизации, вайб-кодингу, промт-инжинирингу, RAG-системам, нейрогенерации и др.
Gemini собрал полезную ПОДБОРКУ экспертов в одну папку. Делюсь списком — внутри только полезный контент про IT & AI.
🔗 Забирай экспертный СПИСОК в один клик: 👉 https://t.me/addlist/1lX_fOkYZXFmZDhk
🔥1
4897. Архитектор предлагает два решения для нового сервиса:
Решение А: облачная инфраструктура Решение Б: покупка собственных серверов on‑premise (капитальные затраты, фиксированная мощность). Какой метод анализа позволит учесть все расходы
Решение А: облачная инфраструктура Решение Б: покупка собственных серверов on‑premise (капитальные затраты, фиксированная мощность). Какой метод анализа позволит учесть все расходы
Anonymous Quiz
29%
ROI (Return on Investment)
61%
TCO (Total Cost of Ownership)
6%
NPV (Net Present Value)
4%
Payback period
TCO – это метод оценки полных затрат на владение и эксплуатацию актива (в данном случае – ИТ-системы) в течение всего жизненного цикла. В отличие от закупочной цены, TCO включает:
Прямые затраты: оборудование (серверы, сетевое оборудование), лицензии на ПО, оплата облачных ресурсов.
Косвенные затраты: электроэнергия, охлаждение, аренда дата-центра, зарплата администраторов, обучение персонала, поддержка, страхование, утилизация оборудования.
Транзакционные затраты: время на миграцию данных, простои при обновлениях, оплата трафика.
Почему для сравнения «облако vs on‑premise» нужен именно TCO?
ROI (A) – показывает прибыль от инвестиций, но требует прогноза доходов, что часто субъективно. ROI не учитывает все эксплуатационные расходы.
NPV (C) – чистая приведённая стоимость, учитывает временную стоимость денег, но требует дисконтирования будущих денежных потоков, что усложняет расчёт и также зависит от прогнозов доходов.
Payback period (D) – срок окупаемости, показывает, когда инвестиции вернутся, но не даёт полной картины затрат на 5 лет.
TCO даёт объективную цифру: «Решение А обойдётся в X миллионов рублей за 5 лет, решение Б – в Y». Это позволяет руководству принимать взвешенное решение без спекуляций.
Реальный пример из практики:
Компания выбирала между AWS и собственным дата-центром. TCO-анализ показал, что on‑premise дешевле при нагрузке > 80% использования серверов, но облако выгоднее при переменной нагрузке (сезонные пики). В итоге выбрали гибридную модель. Без TCO руководство могло бы переплатить миллионы.
Что должен зафиксировать аналитик:
В требованиях к оценке архитектурных альтернатив указать необходимость расчёта TCO на 5 лет.
Включить все категории затрат (не только capex/opex).
Учесть риски (например, рост цен на облачные ресурсы или стоимость утилизации серверов).
Вывод: TCO – обязательный инструмент аналитика при сравнении архитектурных решений, когда речь идёт о многолетних инвестициях. Он даёт объективную основу для переговоров с руководством и финансовым отделом.
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня выигрывает не тот, кто больше работает.
Выигрывает тот, кто умеет привлекать клиентов, строить продажи и правильно использовать маркетинг.
А можно взять готовую базу знаний, где уже собраны материалы по самым важным направлениям:
• продажи и переговоры
• маркетинг и продвижение
• привлечение клиентов
• создание воронок
• монетизация и масштабирование
Эта папка https://t.me/addlist/LcfUVqDykUllYzUy поможет вам быстрее разобраться в том, что действительно приносит деньги, а что только отнимает время.
Если хотите расти в доходе, развивать бизнес и понимать современные инструменты продаж — обязательно подписывайтесь.
Полезные знания окупаются быстрее любых вложений https://t.me/addlist/LcfUVqDykUllYzUy
Записывайся в подборку
Выигрывает тот, кто умеет привлекать клиентов, строить продажи и правильно использовать маркетинг.
Можно годами искать информацию по разным каналам, покупать десятки курсов и совершать одни и те же ошибки.
А можно взять готовую базу знаний, где уже собраны материалы по самым важным направлениям:
• продажи и переговоры
• маркетинг и продвижение
• привлечение клиентов
• создание воронок
• монетизация и масштабирование
Эта папка https://t.me/addlist/LcfUVqDykUllYzUy поможет вам быстрее разобраться в том, что действительно приносит деньги, а что только отнимает время.
Если хотите расти в доходе, развивать бизнес и понимать современные инструменты продаж — обязательно подписывайтесь.
Полезные знания окупаются быстрее любых вложений https://t.me/addlist/LcfUVqDykUllYzUy
Записывайся в подборку