4729. В системе бронирования отелей два менеджера одновременно пытаются забронировать последний номер. Как гарантировать, что номер не продадут дважды?
Anonymous Quiz
16%
Оптимистическая блокировка (проверка версии)
60%
Пессимистическая блокировка (блокировка строки в БД)
8%
Уникальный индекс на номер отеля
15%
Обрабатывать ошибки дубликатов и уведомлять второго
✅ Пессимистическая блокировка — самый надёжный способ. В начале транзакции вы выполняете SELECT ... FOR UPDATE. Эта команда блокирует строку в базе данных до завершения транзакции. Второй менеджер, попытавшись прочитать ту же строку с FOR UPDATE, будет ждать. Когда блокировка снимется, он увидит, что номер уже занят. Это гарантирует, что одновременных бронирований не произойдёт.
❌ Оптимистическая блокировка (A) работает иначе: вы читаете данные без блокировки, запоминаете версию, а при записи проверяете, не изменилась ли версия. В нашем случае оба менеджера прочитают номер как свободный, оба попытаются записать, и один получит ошибку. Это допустимо, но пользователь узнает об отказе только после попытки, что хуже для UX.
❌ Уникальный индекс (C) на поле (hotel_id, room_number) предотвратит вставку дубликата на уровне БД. Но проблема та же: оба менеджера могут попытаться вставить, одна вставка упадёт с ошибкой, второй успеет. Это лучше, чем двойная продажа, но второй менеджер получит неожиданную ошибку.
❌ Обрабатывать ошибки (D) — значит полагаться на то, что приложение само разберётся с конфликтом. Это ненадёжно и усложняет код.
Вывод: Для критически важных ресурсов (билеты, номера, товары) используйте пессимистическую блокировку. Она гарантирует целостность и даёт пользователю мгновенную обратную связь.
Please open Telegram to view this post
VIEW IN TELEGRAM
4730. Мобильное приложение использует API. Разработчики хотят изменить формат ответа, добавив новые поля. Как сделать это без поломки старых версий приложения?
Anonymous Quiz
3%
Оповестить пользователей и попросить обновить приложение
87%
Версионировать API (v1, v2) и поддерживать обе версии параллельно
1%
Менять формат, старые приложения пусть падают
9%
Добавлять поля в конец ответа, старые приложения их проигнорируют
✅ Версионирование API — отраслевой стандарт. Вы начинаете с /api/v1/.... Когда нужно внести изменения, несовместимые со старой версией, вы создаёте /api/v2/.... Старые приложения продолжают работать с v1, новые используют v2. Через некоторое время, когда доля старых клиентов станет ничтожной, вы можете отключить v1. Это гарантирует, что ни одно приложение не сломается.
❌ Оповестить пользователей (A) — не работает. Пользователи не обновляют приложения мгновенно, некоторые могут вообще не обновить. Вы не можете полагаться на их действия.
❌ Пусть падают (C) — недопустимо для серьёзного продукта. Это потеря пользователей и репутации.
❌ Добавлять поля в конец (D) — работает только для добавления необязательных полей, но не для изменений структуры. Если нужно переименовать поле или изменить тип данных, старые приложения сломаются.
Вывод: Версионирование API должно быть заложено в архитектуру с самого первого дня. Это единственный способ эволюционировать систему, не ломая клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Кажется, знакомая история, не правда ли? Бесконечный поиск "волшебной таблетки" в мире онлайн-маркетинга может вымотать кого угодно. Обещания золотых гор, гуру, предлагающие секретные формулы успеха, и горы потраченных впустую денег.
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
Результат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Добавляй себе всю папку https://t.me/addlist/wW0ESLUtsM0wZTQy и
Записывайся в подборку🫶
Чувствуете себя белкой в колесе, которая крутится, но не двигается с места?
🔥ПРИВЛЕКАЙ ПОДПИСЧИКОВ И ПОЛУЧАЙ ЕЖЕДНЕВНЫЕ ЗАЯВКИ БЕСПЛАТНО, С ПОМОЩЬЮ ЭТОГО МЕТОДАРезультат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Добавляй себе всю папку https://t.me/addlist/wW0ESLUtsM0wZTQy и
Записывайся в подборку
Please open Telegram to view this post
VIEW IN TELEGRAM
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