Services Helperмаркетплейс услуг

Две стороны, смоделированные раздельно

Клиент и специалист — не один пользователь с флагом роли. Общих данных у них почти нет: у специалиста профиль, портфолио, подписка и рейтинг; у клиента — заказы. Мы смоделировали их отдельными сущностями за единым уровнем сессионной авторизации.

Права остаются однозначными: эндпоинт принадлежит одной стороне, а не «пользователю, который может быть любым». Публичный профиль тоже отделён от записи аккаунта — чтобы рейтинг и подписка, которые переписываются постоянно, не задевали строку, от которой зависит авторизация.

Цикл маркетплейса

Сделку несут четыре статуса. Клиент публикует OPEN-заказ: категория, город, дедлайн, файлы. Специалисты присылают отклики — предложения на него. Клиент принимает одно, переводя заказ в IN_PROGRESS, далее COMPLETED или CANCELLED.

Отклики — отдельные записи, а не прямое назначение, поэтому клиент сравнивает нескольких специалистов, а не получает одного назначенного.

Как находят нужного специалиста

Поиск работает по осям «что» и «где». Заказы и профили привязаны к категории и городу, поэтому сантехник из Львова не появится в заказе по Одессе.

Отдельного поискового движка нет. На таком объёме каталога индексированные запросы в PostgreSQL по категории, городу и рейтингу быстрее в разработке и дешевле в эксплуатации, чем добавление Meilisearch, — и держат выдачу согласованной с данными. Тариф подписки учитывается в ранжировании: именно это делает платное продвижение стоящим денег, не давая ему перекрыть релевантность.

Удержать сделку на платформе

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

Репутация в обе стороны

Отзывы работают в обоих направлениях. Односторонняя оценка защищает только покупателя, но здесь специалист рискует не меньше — неявки, споры об объёме, неоплата. Видимая история с обеих сторон делает платформу безопасной не только чтобы покупать, но и чтобы работать.

Монетизация без платы за доступ

Опубликовать заказ и откликнуться — бесплатно. Специалисты платят за охват: тарифы подписки и платное продвижение через Stripe. Плата за лид облагала бы именно то поведение, которого маркетплейсу нужно больше.

Состояние подписки ведёт Stripe через webhooks — ACTIVE, PAST_DUE, UNPAID, CANCELED — и проверки доступа читают этот живой статус, поэтому неудавшийся платёж сужает охват, а не оставляет платную функцию открытой.

Чего требовал продакшен

Уведомления — это события, а не вызовы: каждое действие выпускает событие, а обработчики превращают его в запись в приложении и письмо, поэтому бизнес-логика не умеет отправлять почту. Жалобы проходят настоящую машину состояний с обработкой в админке — без модерации маркетплейс услуг наполняется спорами, которые не может решить. Рейт-лимитинг, HTTP-защита, подтверждение почты и медиа в Cloudinary были с первого деплоя.