Okiyumi Rent

Ручная аренда не масштабируется надёжно: следить, какой аккаунт свободен, выдавать данные достаточно быстро после оплаты, хранить их безопасно, обрабатывать продления и возвраты, восстанавливаться после сбоев. Каждый ручной шаг — упущенный заказ или риск безопасности.

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

Заказ приходит с маркетплейса или из Telegram. Система находит здоровый аккаунт, создаёт аренду, доставляет покупателю свежие данные, следит за временем, обрабатывает продление или возврат и возвращает аккаунт в пул по завершении — с ротацией пароля до следующей выдачи.

Мультитенантное ядро, единый бизнес-конвейер: подтверждение оплаты, выдача, продление и возврат живут в одном race-protected движке, поэтому бизнес-правила существуют ровно в одном месте. PostgreSQL с Prisma; тенанты изолированы по дизайну, а не по договорённости.

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

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

В продакшене как часть экосистемы Okiyumi.

В операционно-тяжёлых системах краевые случаи и есть продукт: продления, возвраты и восстановление заслуживают той же инженерной строгости, что и счастливый путь.