4731. Мобильное приложение использует API. Разработчики хотят изменить формат ответа, добавив новые поля. Как сделать это без поломки старых версий приложения?
Anonymous Quiz
2%
Оповестить пользователей и попросить обновить приложение
91%
Версионировать API (v1, v2) и поддерживать обе версии параллельно
1%
Менять формат, старые приложения пусть падают
6%
Добавлять поля в конец ответа, старые приложения их проигнорируют
✅ Версионирование API — отраслевой стандарт. Вы начинаете с /api/v1/.... Когда нужно внести изменения, несовместимые со старой версией, вы создаёте /api/v2/.... Старые приложения продолжают работать с v1, новые используют v2. Через некоторое время, когда доля старых клиентов станет ничтожной, вы можете отключить v1. Это гарантирует, что ни одно приложение не сломается.
❌ Оповестить пользователей (A) — не работает. Пользователи не обновляют приложения мгновенно, некоторые могут вообще не обновить. Вы не можете полагаться на их действия.
❌ Пусть падают (C) — недопустимо для серьёзного продукта. Это потеря пользователей и репутации.
❌ Добавлять поля в конец (D) — работает только для добавления необязательных полей, но не для изменений структуры. Если нужно переименовать поле или изменить тип данных, старые приложения сломаются.
Вывод: Версионирование API должно быть заложено в архитектуру с самого первого дня. Это единственный способ эволюционировать систему, не ломая клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4732. На диаграмме классов отношение, показывающее, что один класс является частным случаем другого
Anonymous Quiz
12%
Ассоциация
12%
Агрегация
66%
Наследование
10%
Зависимость
Please open Telegram to view this post
VIEW IN TELEGRAM
4733. Вы разрабатываете систему обработки заказов для интернет-магазина.
Какой подход к использованию брокера сообщений лучше всего соответствует этим требованиям?
Какой подход к использованию брокера сообщений лучше всего соответствует этим требованиям?
Anonymous Quiz
52%
RabbitMQ с персистентными очередями, подтверждениями от потребителя и постановкой при сбое.
28%
Kafka с одним partition на каждого пользователя.
10%
Amazon SQS с FIFO очередью и Dead Letter Queue для необработанных сообщений.
10%
Активная очередь на базе PostgreSQL (таблица с SELECT ... FOR UPDATE SKIP LOCKED).
🤔4
acks=all гарантирует, что сообщение считается записанным только после подтверждения от всех реплик – потеря данных исключена.
enable.idempotence=true предотвращает дублирование сообщений при повторных попытках продюсера (даёт exactly-once семантику на стороне записи).
Партиционирование по ключу (например, userId) гарантирует строгий порядок сообщений в рамках одной партиции.
Consumer с isolation.level=read_committed читает только зафиксированные транзакции, избегая чтения незавершённых записей.
❌ Почему не другие варианты:
A (RabbitMQ): Обеспечивает at-least-once, но не exactly-once без сложных доработок на стороне потребителя (дедупликация). Порядок сохраняется только в рамках одной очереди при одном потребителе, но при масштабировании порядок может нарушиться.
C (SQS FIFO): Технически тоже подходит (гарантирует exactly-once и порядок), но имеет ограничения по пропускной способности (3000 сообщений в секунду) и менее гибок для сложной потоковой обработки.
D (БД как очередь): Не является брокером сообщений, создаёт высокую нагрузку на БД, сложно масштабируется и не даёт встроенных гарантий exactly-once без дополнительной логики.
Вывод: Для систем с требованиями порядка, exactly-once и отказоустойчивости Kafka — индустриальный стандарт.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
4734. В RabbitMQ при ошибке обработки сообщение возвращается в очередь, вызывая бесконечный цикл. Как этого избежать?
Anonymous Quiz
1%
Добавить больше потребителей
3%
Удалять сообщения при первой ошибке
2%
Перезапускать потребителя при каждом сбое
94%
Настроить Dead Letter Queue для сообщений после нескольких неудачных попыток
Dead Letter Queue (DLQ) — это отдельная очередь, куда попадают сообщения, которые не смогли обработаться после нескольких попыток. Как это работает:
1️⃣ Вы задаёте правило: например, при ошибке кладём сообщение обратно, но не сразу, а через 5, 30, 60 секунд (экспоненциальная задержка).
2️⃣ Если после 3-х попыток сообщение так и не обработалось — оно отправляется в DLQ.
3️⃣ В DLQ эти «проблемные» сообщения ждут ручного разбора, анализа или автоматической обработки по другому сценарию.
❌ Почему не подходят другие варианты:
A (больше потребителей) — как увеличить количество рабочих на конвейере с бракованной деталью: они будут просто быстрее прогонять по кругу тот же брак.
C (удалять при ошибке) — данные безвозвратно теряются. А вдруг это был важный заказ или платёж?
B (перезапуск потребителя) — проблема не в потребителе, а в данных. Перезапуск не исправит кривой JSON.
Вывод для аналитика: В требованиях к интеграциям всегда указывайте необходимость DLQ. Это гарантия, что система не «зависнет» из-за одного плохого сообщения, а данные не потеряются. 📨🛡
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
4736. При интеграции с платежным сервисом система получила код 429 (Too Many Requests). Разработчик обработал его как фатальную ошибку, хотя бизнес ожидал автоматических повторов. Где возникла проблема?
Anonymous Quiz
1%
Разработчик неверно понял код ответа
9%
Тестировщик не проверил сценарий с 429
76%
Аналитик не описал поведение системы для разных HTTP-кодов
13%
Архитектор не заложил механизм retry
👍1
❌ Почему не другие варианты:
A (Разработчик) — он строго следовал ТЗ, где не было указаний по обработке 429. Если в требованиях написано «при ошибке прерывать операцию», разработчик поступил корректно.
B (Тестировщик) — тестировщик проверяет только задокументированные сценарии. Без требования сценарий с 429 не включается в тест-план.
D (Архитектор) — архитектор может предложить общий механизм повторных попыток (retry policy), но конкретные условия — какие коды должны вызывать повторы, сколько попыток делать, с какими интервалами — это зона ответственности аналитика, который описывает функциональное поведение системы.
Корень проблемы: Аналитик не заложил в требованиях обработку различных HTTP-кодов ответа от внешнего сервиса. Интеграционные сценарии часто содержат множество нюансов: временные ошибки (429, 503), требующие повтора; ошибки валидации (400), требующие корректировки данных; ошибки авторизации (401, 403), требующие обновления токена.
Что должен был сделать аналитик:
Изучить документацию внешнего сервиса и выписать все возможные коды ответа.
Для каждого кода согласовать с бизнесом ожидаемое поведение системы:
200 — успех, идём дальше.
400 — ошибка в данных, показываем пользователю, что нужно исправить.
429 — временная ошибка, автоматически повторяем до 3 раз с интервалом 5, 30, 60 секунд.
500 — ошибка сервера, повторяем 3 раза, если не успешно — уведомляем администратора.
Задокументировать это в виде понятной таблицы или матрицы решений.
Последствия отсутствия таких требований:
Разработчик принимает решение на основе своего опыта (часто ошибочного).
Тестировщик не проверяет непрописанные сценарии.
В прод уходит функционал, который не соответствует ожиданиям бизнеса.
Пользователи видят ошибки там, где могли бы быть автоматические повторы.
Вывод: Полнота требований к интеграциям — прямая ответственность аналитика. Чем детальнее прописано поведение системы во всех возможных ситуациях, тем меньше рисков на этапах разработки и тестирования. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4737. Банк обновил версию API для проверки кредитных историй. Разработчики протестировали новую версию, всё работало. Через неделю старая версия API отключилась, и система перестала выдавать кредиты. В чём первопричина?
Anonymous Quiz
13%
Разработчики не учли отключение старой версии
22%
Тестировщики не проверили сценарий без старого API
51%
Аналитик не описал требование к graceful degradation при недоступности внешнего сервиса
14%
Архитектор не заложил механизм автоматического переключения
❌ Почему не другие варианты:
A (Разработчики) — они реализовали поддержку новой версии, но не знали, что старая скоро отключится, и не закладывали логику переключения.
B (Тестировщики) — тестировали то, что написано в требованиях. Без требования о graceful degradation этот сценарий не включается в план тестирования.
D (Архитектор) — может предложить решение (балансировку, fallback), но только если в требованиях указана необходимость непрерывности работы.
Что должен был сделать аналитик:
При описании интеграции указать: «Система должна поддерживать обе версии API в течение переходного периода».
Прописать поведение при недоступности API (например, отложить обработку, уведомить администратора, использовать кэшированные данные).
Включить в приёмочные тесты сценарии отключения старой версии и потери связи с новой.
Вывод: Надёжность системы закладывается на уровне требований, а не обнаруживается после падения в проде. 📉
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Как находят работу за бугром в IT
Наити работу на немецком рынке. И не через релокацию! Сам нашел и сам переехал!
Это история Бизнес аналитика, который работает в Deutsche Bank и язвительно пишет из солнечного Франкфурта-на-Майне.
Из ХЗ в ТЗ — блог про работу в финтехе и как там у них. Антон также исследует рынок РФ и продолжает ходить на собеседования.
Истории, которые уже вышли:
🟢 собеседование в банк Азии на 380К. Кринж😬
🟢 красные флаги в тестовом задании. И референс ответа.
🟢 как мы делали mit den Jungs в банке
🟢 стал бы я в 2026-ом накручивать опыт в резюме?
Переходите знакомиться: @anton_alekseev
Наити работу на немецком рынке. И не через релокацию! Сам нашел и сам переехал!
Это история Бизнес аналитика, который работает в Deutsche Bank и язвительно пишет из солнечного Франкфурта-на-Майне.
Из ХЗ в ТЗ — блог про работу в финтехе и как там у них. Антон также исследует рынок РФ и продолжает ходить на собеседования.
Истории, которые уже вышли:
🟢 собеседование в банк Азии на 380К. Кринж😬
🟢 красные флаги в тестовом задании. И референс ответа.
🟢 как мы делали mit den Jungs в банке
🟢 стал бы я в 2026-ом накручивать опыт в резюме?
Переходите знакомиться: @anton_alekseev
4738. Вы пишете запрос для отчета по продажам. Нужно получить список товаров, у которых общая сумма продаж превышает 100 000 рублей. Как правильно написать условие?
Anonymous Quiz
32%
WHERE SUM(sales_amount) > 100000
53%
HAVING SUM(sales_amount) > 100000
4%
FILTER SUM(sales_amount) > 100000
11%
GROUP BY с условием в SELECT