4889. Клиент отправляет запрос на списание денег. Из-за сетевого таймаута он повторяет запрос. Сервер обрабатывает оба, и деньги списываются дважды. Какая техника на стороне сервера предотвращает повторную обработку без изменения бизнес-логики?
Anonymous Quiz
92%
Уникальный идентификатор транзакции в теле запроса (idempotency key)
4%
Проверка IP-адреса клиента
0%
Создание вопросов по базам данных - DeepSeek
4%
Использование HTTP-метода DELETE вместо POST
А знаете, кто сейчас получает самое большое преимущество?
Не те, кто работает больше.
А те, кто научился работать вместе с ИИ.
Поэтому собрал папку с сильными экспертами в этой теме
Не те, кто работает больше.
А те, кто научился работать вместе с ИИ.
Поэтому собрал папку с сильными экспертами в этой теме
HTTP POST не является идемпотентным по определению. Если клиент повторяет запрос из-за таймаута, сервер не может отличить повтор от нового запроса. Это приводит к дублированию операций (списаний, созданий заказов).
Решение – идемпотентный ключ (Idempotency Key):
Клиент генерирует уникальный ключ (например, UUID) и передаёт его в заголовке
Idempotency-KeyАлгоритм работы сервера:
Получить ключ из заголовка.
Проверить в хранилище (Redis, БД), есть ли уже выполненная операция с этим ключом.
Если есть – вернуть сохранённый ответ.
Если нет – выполнить операцию (списание денег), сохранить ключ и результат, затем вернуть ответ.
Пример кода (Node.js):
javascript
const idempotencyKey = req.headers['idempotency-key'];
const cached = await redis.get(idempotencyKey);
if (cached) return JSON.parse(cached);
const result = await processPayment(req.body);
await redis.setex(idempotencyKey, 86400, JSON.stringify(result));
res.json(result);
Почему не подходят другие варианты:
B (IP-адрес) – не надёжен: несколько клиентов за NAT, динамические IP.
C (rate limiting) – не решает дублирование из-за таймаута, а лишь ограничивает частоту.
D (DELETE) – не подходит для создания ресурса/списания средств.
Реальный пример:
Stripe требует обязательный заголовок
Idempotency-KeyЧто должен зафиксировать аналитик:
«API должен поддерживать заголовок Idempotency-Key для всех небезопасных методов (POST, PUT, PATCH)».
«Ключ должен храниться не менее 24 часов».
«Ответ на повторный запрос с тем же ключом должен быть идентичен первому».
Вывод: Idempotency Key – стандарт защиты от двойной обработки в REST API, обязательный для финансовых и критических операций.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
IT & Digital
Папка для тех, кто погружен в мир разработки, программирования, данных, ИИ, цифрового маркетинга, аналитики, UX/UI дизайна, управления IT-проектами и развития tech-продуктов.
👉 Сохранить себе
Папка для тех, кто погружен в мир разработки, программирования, данных, ИИ, цифрового маркетинга, аналитики, UX/UI дизайна, управления IT-проектами и развития tech-продуктов.
👉 Сохранить себе
4890. В системе 10 микросервисов. Нужно показать, как запрос на оформление заказа проходит через них, с указанием порядка вызовов (1, 2, 3…). Какая диаграмма UML лучше подходит, когда важны не временные отрезки, а структура взаимодействия?
Anonymous Quiz
66%
Диаграмма последовательности (Sequence)
29%
Диаграмма коммуникации (Communication)
2%
Диаграмма классов
3%
Диаграмма деятельности
Когда что использовать:
Диаграмма последовательности – лучше для детального анализа временнóй логики, асинхронных вызовов, параллельных процессов. Но при 10 сервисах она становится громоздкой (много линий времени).
Диаграмма коммуникации – компактнее для большого числа участников, хорошо показывает, кто с кем связан, и позволяет быстро пронумеровать вызовы. Отлично подходит для архитектурных обсуждений на доске.
Почему B правильный ответ:
В задаче важны не временные отрезки (сколько миллисекунд), а порядок вызовов и структура связей. Диаграмма коммуникации помещает все микросервисы на один лист и стрелками с номерами показывает последовательность. Это удобно для презентации архитектуры команде и стейкхолдерам.
Реальный пример:
В интеграционном проекте с 6 внешними сервисами диаграмма коммуникации помогла выявить циклические зависимости (А → Б → В → А), которые не замечали на диаграмме последовательности.
Что должен зафиксировать аналитик:
Для описания высокоуровневого потока с большим числом участников использовать диаграмму коммуникации.
Для детальной отладки с таймингами – диаграмму последовательности.
Вывод: Диаграмма коммуникации незаменима, когда нужно показать упорядоченные взаимодействия между многими участниками, не загромождая временными полосками.
Please open Telegram to view this post
VIEW IN TELEGRAM
4891. Команда выпускает новую версию микросервиса, но при обновлении возникает простой 2 минуты, пока старые поды заменяются новыми. Какой стратегией деплоя можно полностью исключить простой и мгновенно переключать трафик между средами?
Anonymous Quiz
32%
Rolling update
47%
Blue‑Green deployment
20%
Canary deployment
1%
A/B тестирование
Новая версия разворачивается в зелёной среде, пока синяя продолжает обслуживать трафик.
Проводятся smoke-тесты зелёной среды.
В один момент (атомарно) переключается маршрутизатор (балансировщик, DNS), и весь трафик направляется на зелёную среду.
Если возникли проблемы – переключаем обратно на синюю за секунды.
Синяя среда сохраняется как резервная, позже удаляется.
Почему отсутствует простой:
Переключение трафика происходит мгновенно (обновление конфигурации балансировщика или смена DNS-записи). Старые поды не удаляются до переключения, поэтому пользователи не замечают никакого прерывания.
Сравнение с другими стратегиями:
Rolling update (A) – постепенная замена подов. Может быть почти незаметным, но требует, чтобы приложение было отказоустойчивым к разным версиям одновременно. Риск – простой при ошибке в последней партии.
Canary deployment (C) – сначала новая версия получает небольшой процент трафика (например, 1%), что позволяет оценить работу, но для бездымного переключения на 100% также нужен финальный атомарный шаг.
A/B тестирование (D) – не про деплой, а про эксперименты.
Реальный пример:
В Netflix используется Blue‑Green для критических сервисов. Перед переключением проводят полный цикл интеграционного тестирования в зелёной среде. При обнаружении проблем – просто не переключают трафик.
Что должен зафиксировать аналитик:
Требование: «Критические сервисы должны разворачиваться по стратегии Blue‑Green с нулевым временем простоя».
Наличие двух полных окружений (ресурсы могут быть уменьшены на время, но должны быть готовы к переключению).
Процедура отката – переключение обратно на blue.
Вывод: Blue‑Green deployment – золотой стандарт для систем, где недопустим простой, но требует удвоения ресурсов во время деплоя.
Please open Telegram to view this post
VIEW IN TELEGRAM
Нейросети, IT и AI — в одной папке
💬 С коллегами собрали новые каналы про:
💠 промпты для нейросетей и готовые решения
💠 AI-фотосессии, генерация изображений и контента
💠 новости искусственного интеллекта без лишнего шума
💠 применение AI в работе, бизнесе и повседневной жизни
💠 Python, JavaScript, Data Science и системный анализ
💠 вакансии и возможности для специалистов в IT
Посмотреть и подписаться тут 👉 https://t.me/addlist/c_rbhnzprbAwMmFi
💌 Добавить свой канал в папку
💬 С коллегами собрали новые каналы про:
💠 промпты для нейросетей и готовые решения
💠 AI-фотосессии, генерация изображений и контента
💠 новости искусственного интеллекта без лишнего шума
💠 применение AI в работе, бизнесе и повседневной жизни
💠 Python, JavaScript, Data Science и системный анализ
💠 вакансии и возможности для специалистов в IT
Посмотреть и подписаться тут 👉 https://t.me/addlist/c_rbhnzprbAwMmFi
💌 Добавить свой канал в папку
4892. API возвращает поле customer_name. В новой версии поле переименовали в full_name. Чтобы не ломать старых клиентов, сервер должен поддерживать обе версии одновременно. Как клиент может указать, какую версию API он хочет получить?
Anonymous Quiz
12%
Добавить параметр ?version=2 в URL
23%
Указать версию в заголовке Accept: application/vnd.myapi.v2+json
61%
Использовать разные endpoint-ы /v1/customers и /v2/customers
4%
Передать версию в теле запроса
Способы версионирования:
Через 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