Собеседование Python-разработчика: идемпотентность и Transactional Outbox

Коротко о видео

Реальное интервью начинается с архитектурной задачи: сервис получает платёжную инструкцию из брокера, обновляет балансы с учётом комиссии и отправляет результат в другой брокер. Кандидат предлагает идемпотентного consumer, транзакцию БД, блокировки счетов и Transactional Outbox. Интервьюер уточняет порядок подтверждения сообщений, возможные дубли при падении после отправки и работу relay-воркеров с select for update skip locked. Обсуждаются статусы сообщений, повторная доставка и альтернатива через Change Data Capture и Debezium. Затем беседа переходит к работе с легаси, обоснованию рефакторинга перед бизнесом и реальной вакансии: набор сервисов для customer success, ожидание ownership и несколько открытых Senior Python-ролей.

Затронутые темы

Что взять на заметку

• Идемпотентный consumer должен учитывать повторную доставку и хранить состояние обработки сообщения.
• Изменение балансов и запись в Outbox выполняются в одной транзакции БД.
• Подтверждение доставки в брокер и фиксация статуса Outbox нельзя считать одной атомарной операцией: при падении возможна повторная отправка.
• Relay-воркеры могут брать записи Outbox конкурентно через SELECT FOR UPDATE SKIP LOCKED, но для окна между успешной публикацией и фиксацией статуса нужна дедупликация или идемпотентность у получателя: одних статусов недостаточно.
• Рефакторинг легаси нужно обосновывать рисками, стоимостью поддержки и ожидаемой пользой для бизнеса.