ВЕБ ШТУРМ
Обсудить →

Сложные системы

Бронирование, платежи, документооборот, ГИС-интеграции, многофронтенд на одной БД

Строим веб-системы с многослойной логикой: бронирование с расчётом цен и скидок, платежи (СБП, эквайринг), документооборот с генерацией PDF, государственные интеграции (ГИС ЭП — Электронная Путёвка, ЕГИС ОТБ — Обеспечение Транспортной Безопасности), многофронтенд на единой БД с RLS.

Что входит

  • Backend на Supabase Postgres 17 с Row Level Security, Edge Functions (Deno), self-hosted развёртывание на инфраструктуре заказчика.
  • Frontend на SvelteKit 2 + Svelte 5 runes + Tailwind 4 с компонентной библиотекой shadcn-svelte и bits-ui. Production-стек.
  • Очереди и workflows через Hatchet на той же Postgres-схеме. Заменили самописный PDFKit-pipeline.
  • PDF-генерация через Gotenberg (HTML→PDF) — stateless, масштабируется горизонтально. У нас 9 LIVE PDF-шаблонов в работе.
  • Платежи через shared-pay (СБП Альфа-банк, ЮKassa) с выделенным pay-service для критичных callback’ов.
  • Версионирование через valid_from — единая модель для discounts, prices, booking_rules, promotions, document templates.

Когда нужно

  • Бизнес-логика сложнее CRUD — нужны правила бронирования, расчёт скидок, эффективные даты.
  • Несколько продуктов на одной клиентской базе (B2C + агентский, основной + дочерний).
  • Документооборот: ваучеры, расписания, договоры — нужна автоматическая генерация с шаблонами.
  • Госинтеграции: Минтранс ГИС ЭП (Электронная Путёвка), ЕГИС ОТБ (АЦБПДП ≤30 мин), 1С через REST OData.

Как мы работаем

  1. Архитектурный спринт (1-2 недели). Доменная модель, схема БД, выбор стека, оценка трудоёмкости по этапам.
  2. MVP (1-2 месяца). Один сценарий end-to-end: бронирование → оплата → документ → уведомление. Production-deploy в staging.
  3. Расширение по этапам. Добавляем сценарии, роли, интеграции. Релизы каждые 1-2 недели.
  4. Передача и поддержка. Документация, обучение, SLA на uptime ≥99.5%.

Технологии

SvelteKit 2, Svelte 5, Supabase PG 17, Hatchet TS SDK v1, Gotenberg 8, Альфа-банк SBP, ЮKassa, mTLS + HMAC + Idempotency для inter-service auth, Caddy auto-TLS, Docker Compose. Интеграции: ГИС ЭП Минтранса, 1С (REST OData), Яндекс.Карты (lazy через IntersectionObserver).

Подробности — в кейсах Круизный флот и Прогулочный флот.

Опишите задачу — обсудим как закрыть её целиком.

Часто задаваемые вопросы

Сколько одновременных пользователей выдерживает ваша архитектура?
Текущие продукты Круизный флот + Прогулочный флот в production поддерживают ≥1000 одновременных пользователей (требование ТЗ заказчика). Узкое место — обычно не БД, а сторонние интеграции (платёжный шлюз, legacy API).
Используете ли вы микросервисы?
Только там, где это оправдано: shared-pay (платёжный шлюз) и pay-service (callback-handler) — отдельные сервисы. Остальное — модульный монолит на SvelteKit + Supabase. Микросервисная сложность включается, когда есть реальная нагрузка.
Как вы организуете многофронтенд на одной БД?
Принцип: основной продукт = primary, остальные = derived через `$shared` alias. У нас Круизный флот = primary, Прогулочный флот = derived. Это даёт переиспользование 80% кода без vendor lock между продуктами.
Чем отличается ваш подход к версионированию?
Вместо `valid_to`/`is_active` (race conditions, конфликты) используем insert-only с `valid_from`. Резолвер: `max(valid_from) ≤ effective_date`. Старые версии неприкосновенны, история полная, конфликтов нет.
Какие платёжные шлюзы поддерживаете?
Production-опыт: Альфа-банк СБП C2B, ЮKassa. Готовы интегрировать любой со зрелым REST API. Callback-обработка через выделенный pay-service для атомарности.

Готовы обсудить проект?

Напишите — обсудим задачу и сроки.

Обсудить проект →