Опубликовано: 12.09.2026 | Источник: ComNews

Сервис защиты сделок в ВКР: проектирование escrow-логики на кейсе «Авито Услуг»

Введение

23 марта 2026 года «Авито Услуги» запустили тест партнёрского сервиса, который меняет саму логику заказа услуг и расчётов между заказчиком и исполнителем. Механика простая на словах и очень непростая в реализации: платформа фиксирует договорённости сторон и структурирует процесс — от подтверждения заказа до момента, когда деньги уходят исполнителю. Фактически речь о встроенном escrow-слое внутри маркетплейса.

Почему это важно для выпускника ИТ-специальности? Потому что здесь сходятся все классические задачи бэкенда: транзакционная целостность, идемпотентность платёжных операций, конечный автомат состояний сделки, разграничение прав, обработка споров и аудит. Такая тема легко превращается в ВКР, где есть что проектировать, что реализовывать и что измерять. И защищать её куда проще, чем очередную «информационную систему учёта книг в библиотеке».

FAQ: что спрашивают студенты до старта

Темы ВКР на базе кейса

Ниже — три варианта, от самого «архитектурного» до самого прикладного. Выбирайте по тому, что вам ближе: проектировать, кодить или измерять.

• Тема 1. Проектирование сервиса доверительных расчётов для маркетплейса услуг.
  Актуальность: кейс «Авито Услуг» показывает, что платформы уходят от простого матчинга к гарантированной сделке — это прямой запрос рынка.
  Цель: разработать архитектуру сервиса, обеспечивающего безопасный расчёт между заказчиком и исполнителем.
  Задачи: анализ существующих моделей эскроу; формализация жизненного цикла сделки; проектирование API и хранилища состояний; выбор механизма разрешения споров.
  Структура: Гл. 1 — анализ предметной области и аналогов; Гл. 2 — архитектура (C4, модели данных, OpenAPI-спецификация); Гл. 3 — прототип, тестирование сценариев отказа, оценка метрик.
• Тема 2. Реализация конечного автомата сделки с идемпотентной обработкой платежей.
  Актуальность: без строгого автомата состояний и защиты от повторных запросов escrow-логика разваливается на двойных списаниях и «зависших» заказах.
  Цель: реализовать ядро сервиса, устойчивое к сетевым сбоям и повторным вызовам.
  Задачи: построить диаграмму состояний; реализовать идемпотентные эндпоинты (Idempotency-Key); настроить транзакционную отправку событий; провести нагрузочное тестирование.
  Структура: Гл. 1 — теория распределённых транзакций и паттернов Saga/Outbox; Гл. 2 — реализация ядра и API; Гл. 3 — функциональное и нагрузочное тестирование, анализ журналов.
• Тема 3. Оценка эффективности и качества escrow-механики по ISO/IEC 25010.
  Актуальность: продуктовая ценность подобного сервиса измеряется не «работает/не работает», а характеристиками качества: надёжность, производительность, защищённость.
  Цель: построить методику оценки сервиса защиты сделок на соответствие модели качества программного продукта.
  Задачи: выбрать применимые характеристики и подхарактеристики; определить метрики и пороги; собрать замеры на прототипе; сформулировать рекомендации.
  Структура: Гл. 1 — обзор стандартов и моделей качества; Гл. 2 — разработка методики и стенда измерений; Гл. 3 — эксперименты, таблицы замеров, выводы.

Как встроить материал статьи в главы ВКР

Глава 1: превращаем новость в обоснование

Не пересказывайте статью своими словами — это слабое место восьми работ из десяти. Нужен аналитический разбор. Составьте таблицу моделей расчётов: прямая оплата, предоплата, постоплата, депонирование, эскроу. По каждой строке — риски заказчика, риски исполнителя, кто держит деньги, кто разрешает спор. Кейс «Авито» становится последней строкой таблицы и одновременно мостиком к постановке задачи. Здесь же уместно вставить BPMN-диаграмму процесса: два пула (заказчик, исполнитель), отдельная дорожка под платформу.

Глава 2: проектирование и реализация

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

• UML State Machine — состояния сделки: DRAFT → AWAITING_PAYMENT → FUNDS_HELD → IN_PROGRESS → AWAITING_CONFIRMATION → RELEASED, плюс ветки DISPUTED, REFUNDED, CANCELLED. Покажите запрещённые переходы — это отдельно оценивают.
• C4 (уровни Context и Container) — платформа, сервис сделок, платёжный шлюз, антифрод, сервис уведомлений.
• UML Sequence — удержание средств и последующая выплата, включая компенсацию при сбое.

Ядро — идемпотентность и корректность переходов. Простейший псевдокод обработчика подтверждения сделки:

def confirm_deal(deal_id: UUID, idempotency_key: str, actor_id: UUID):
    # 1. Защита от повторной обработки
    if idempotency_store.exists(idempotency_key):
        return idempotency_store.get(idempotency_key)

    with db.transaction(isolation="SERIALIZABLE"):
        deal = deal_repo.get_for_update(deal_id)

        if deal.state != DealState.AWAITING_CONFIRMATION:
            raise InvalidTransition(deal.state)
        if actor_id != deal.customer_id:
            raise AccessDenied("только заказчик подтверждает приёмку")

        # 2. Фиксируем переход и событие в одной транзакции (Transactional Outbox)
        deal.state = DealState.RELEASED
        outbox.append(PayoutRequested(deal_id=deal.id, amount=deal.amount))
        deal_repo.save(deal)

    result = {"deal_id": deal_id, "state": "RELEASED"}
    idempotency_store.put(idempotency_key, result, ttl=24h)
    return result

Отдельно распишите обработку сбоя на шаге выплаты. Именно здесь пригодится паттерн Saga с компенсацией: если платёжный шлюз вернул ошибку, сделка переводится в PAYOUT_FAILED, а не откатывается в исходное состояние — иначе баланс и статус разъедутся. Зафиксируйте это правило в тексте, оно показывает зрелость решения.

Глава 3: тестирование и метрики

Не ограничивайтесь «всё запустилось». Нужен управляемый эксперимент: набор из 500–1000 синтетических сделок, прогон через три сценария (успех, спор, отказ платёжного шлюза) и таблица замеров. Метрики поддомена, которые реально оценит комиссия:

Безопасность описывайте по OWASP ASVS хотя бы на уровне проверок аутентификации, авторизации на каждый переход и защиты от подмены идентификаторов сделки. Частая дыра в студенческих проектах — проверка, что пользователь «свой», но без проверки, что он именно участник конкретной сделки.

Чему вы научитесь на такой теме

• Проектировать конечные автоматы для бизнес-процессов и доказывать отсутствие «дырявых» переходов.
• Делать идемпотентные API и объяснять комиссии, зачем нужен Idempotency-Key.
• Применять Saga и Transactional Outbox вместо наивных распределённых транзакций.
• Строить схемы в C4, UML и BPMN и оформлять их по требованиям нормоконтроля.
• Считать метрики производительности и надёжности, а не только «средний ответ сервера».

Источник: На платформе "Авито" тестируют сервис по защите сделок в сегменте услуг (опубликовано 2026-03-23)