Какой реализовал самый сложный проект?

Самый сложный проект: интеграция платёжной системы в маркетплейс

Контекст: почему это был сложный проект

Я руководил запуском интегрированной платёжной системы для маркетплейса с 500+ продавцов и 100k+ активных покупателей. Проект казался простым на словах, но скрывал множество подводных камней.

Сложности проекта

1. Множественность игроков и интересов

У проекта было три группы заинтересованных лиц:

Покупатели: хотели быстрый, безопасный платёж, возврат денег за 1 клик Продавцы: хотели быстрого вывода денег (T+1), низких комиссий, отсутствия ошибок Платёжные провайдеры: требовали определённой архитектуры, изоляции, логирования

Каждая группа имела конфликтующие требования. Например:

• Покупатели хотели расплатиться в 1 клик
• Провайдеры требовали 3D Secure для безопасности
• Продавцы боялись chargebacks из-за дополнительной verификации

2. Регуляторная сложность

Работа с деньгами означает работу с регуляторами:

• PCI DSS compliance — нельзя хранить номера карт
• KYC/AML — знай своего клиента (для продавцов выводящих > 500k)
• Налоговые требования — заполнение 1099 форм для иностранных продавцов
• Договоры с платёжными системами — NDA, требования о шифровании

Случилось так, что один платёжный провайдер запросил изменение архитектуры за 2 недели до запуска. Пришлось переделывать часть системы.

3. Техническая сложность

Асинхронность и idempotency:

• Платёж может потеряться в пути между нами и провайдером
• Нельзя просто переправить запрос — может быть двойной заряд
• Пришлось реализовать idempotent ключи для каждой транзакции

Состояния платежа:

Initiated → Processing → Succeeded
         ↓         ↓
       Failed   Pending (требует доп. подтверждения)
         ↓
      Refunded

Нужно было обрабатывать каждый переход и webhook от провайдера, который может придти в любой момент.

Рекурсия и частичные возвраты:

• Покупатель заказал 5 товаров на $500
• Вернул 2 товара (нужен частичный возврат $200)
• Но один товар уже отправлен продавцу

Пришлось моделировать состояния возвратов, блокировки денег и т.д.

4. Финансовая ответственность

Мы несём ответственность за деньги пользователей. Одна ошибка = потеря доверия и судебные иски.

• Один bag: система не вывела деньги трём продавцам на сумму $50k
• Необходимо было восстановить из логов и переправить вручную
• Пришлось писать отчёт для всех трёх продавцов
• Потеряли одного крупного продавца из-за недоверия

5. Неопределённость требований

Заказчик (CEO) хотел:

• "Платежи работают как у Stripe"

Но мы не Stripe. У нас было:

• Ограниченный бюджет
• Маленькая команда (1 backend, 1 frontend, 1 QA)
• Жёсткие дедлайны (Black Friday через 3 месяца)

Пришлось многое срезать:

• 3D Secure только для рисковых платежей
• Возвраты вручную, не полностью автоматизированные
• Разделение платежей между несколькими картами — не реализовано

Как я справился с этой сложностью

Шаг 1: Декомпозиция проблемы

Вместо того чтобы думать "давайте сделаем платежи", я разбил на слои:

MVP (неделя 1-4):

• Простой платёж: одна карта, одна сумма
• Успех/отказ, больше ничего
• Вывод денег вручную через админку

Phase 2 (неделя 5-8):

• Возвраты (полные)
• Список платежей в личном кабинете
• Уведомления по email

Phase 3 (неделя 9-12):

• Частичные возвраты
• Автоматический вывод денег
• Расширенная аналитика

Это позволило запустить MVP без всех фич, но работающий и безопасный.

Шаг 2: Синхронизация заинтересованных лиц

Создал документ "Requirements Trade-offs":

Все согласились, что это разумные компромиссы для MVP.

Шаг 3: Серьёзное тестирование

Отвели 20% времени только на тестирование:

Unit тесты:

• Каждый переход состояния платежа
• Каждый расчёт комиссии
• Каждый сценарий возврата

Интеграционные тесты:

• Мок платёжного провайдера
• Асинхронные сценарии (платёж приходит с задержкой)
• Webhook'и приходят в неправильном порядке

Stress-тесты:

• 10,000 платежей в секунду
• Провайдер не отвечает 5 минут
• Случайные ошибки сети

Шаг 4: Документирование

Написал три документа:

1. Technical Design Document (10 страниц) — как работает архитектура
2. Runbook (20 страниц) — что делать если что-то сломается
3. Decision Log — почему мы выбрали именно эту архитектуру

Это спасло нас, когда в production произошла ошибка. Мы потратили 2 часа вместо 8.

Шаг 5: Постепенный rollout

Не включили всем сразу:

1. День 1-2: только для нас (внутренние платежи)
2. День 3-4: 1% пользователей (beta тестеры)
3. День 5-7: 10% пользователей
4. День 8+: 100%

На каждом этапе собирали метрики:

• Success rate платежей
• Среднее время обработки
• Ошибки
• Complaints

Нашли и исправили 3 критичных бага на этапе beta.

Ключевые метрики проекта

• Success rate: 99.2% (цель была 99%)
• Time to process payment: 15-25 секунд (цель 30)
• Adoption: 78% пользователей использовали новый способ платежа в первый месяц
• Defection: потеряли только 1 продавца из 500+ (был заранее недоволен)

Lessons Learned

1. Регуляция стоит денег

Когда работаешь с деньгами, нельзя скайпить compliance. Проще потратить 20% бюджета на правильность, чем потом судиться.

2. Асинхронность — враг

Всё, что может пойти не так асинхронно, пойдёт не так. Логируй всё. Используй очереди. Тестируй race conditions.

3. Требования конфликтуют

Нельзя угодить всем. Лучше честно обсудить trade-offs и выбрать одно направление.

4. Документирование спасает

Время, потраченное на документ сейчас = часы экономии потом.

5. Gradual rollout спасает от паники

Лучше найти 3 бага на 1% юзеров, чем 300 багов на 100% юзеров.

Итог

Самый сложный проект в моей карьере показал мне, что сложность — это не только техника, это политика, регуляция, асинхронность и неопределённость. Успешно справился потому что разбил на части, документировал, тестировал и медленно катил. Скорость — враг, когда деньги на кону.