Backend без микросервисного хаоса⁠ и без «от 8 месяцев».

По умолчанию — два варианта. Java и Spring Boot — для платформ со сложной бизнес-логикой, B2B-маркетплейсов, проектов с многолетней поддержкой. Node.js, TypeScript и NestJS — для SaaS, AI-первых продуктов, проектов с тесной связкой с Next.js-фронтом. PostgreSQL — основная база в обоих случаях. Стек выбирается на архитектурном спринте под конкретную задачу.

Потому что в 80% случаев, когда заказчик говорит «нам нужны микросервисы», за этим стоит мода или совет знакомого, а не реальные разные нагрузки и команды. До 4+ инженеров, реальной разной нагрузки на части продукта и отдельной DevOps-команды правильный ответ — модульный монолит. Это дешевле в разработке, проще в поддержке и легко мигрируется в микросервисы потом, когда правда нужно.

Да, это типичный сценарий — тариф 030-E «Backend для готового фронта». Подключаем API под существующие экраны на Next.js или React Native, поднимаем модель данных, авторизацию, бизнес-логику и интеграции. Без переписывания фронта.

Тариф 030-F «Стабилизация и производительность» — подключаемся через аудит (030-B), фиксируем самые опасные участки, переписываем хрупкие модули, чиним интеграции, добавляем мониторинг. Если систему правильнее переписать с нуля — честно говорим это в отчёте аудита.

Зависит от масштаба. До сотен тысяч активных пользователей и десятков тысяч RPS — да, наша архитектура (модульный монолит, PostgreSQL с правильными индексами, Redis для кэша и очередей, CDN, горизонтальное масштабирование) это покроет. Миллион+ RPS, банковский core, биржевые системы — рекомендуем Рексофт, СимбирСофт или внутренние команды банков.

1С — через REST/OData или интеграционный шлюз. CRM (AmoCRM, HubSpot, Битрикс24) — webhooks + API. Платежи — ЮKassa, Тинькофф, СБП, Stripe. Email/SMS — Mailgun, SendPulse, Twilio. На спринте фиксируем источник истины для каждого типа данных, что синхронно, что асинхронно, как обрабатываются ошибки и повторы. Идемпотентность — по умолчанию, не «потом добавим».

Авторизация — JWT или сессии (зависит от типа продукта), права проверяются на каждую операцию, видимость данных — по роли и владельцу. Для регулируемых проектов — журнал действий, история изменений, контроль за доступом. 152-ФЗ — реальные технические контроли, а не маркетинг: хранение данных в РФ, журналы доступа, шифрование в покое и в движении.

REST с OpenAPI — основной выбор. GraphQL — когда правда нужно (сложные связанные данные, мобильное приложение с переменными представлениями, несколько фронтов с разными нуждами). tRPC — для tight TypeScript-связки с Next.js, когда backend и фронт в одном монорепо.

Юнит-тесты на бизнес-логику, интеграционные тесты на API, отдельный набор тестов на интеграции с внешними системами (с моками), нагрузочные тесты перед запуском платных функций. Coverage — не самоцель, цель — чтобы критические сценарии (оплата, авторизация, права) были покрыты тестами.

Для SaaS и стартапов — Vercel/Railway/Render, быстрый старт, минимальный DevOps-оверхед. Для крупных платформ — Kubernetes на проверенном провайдере. Для регулируемых проектов — self-hosted на российских провайдерах (Yandex Cloud, Selectel). CI/CD — GitHub Actions, автоматический деплой на staging, ручной — на прод.

Да, тариф 030-G «Развитие и поддержка backend» — от 150 тыс. ₽/мес. Та же команда, которая делала backend, продолжает его развивать: новые функции, архитектурные ревью, поддержка интеграций, мониторинг, дежурство по критическим инцидентам. Это не «команда поддержки из джунов», а те же senior-инженеры.

С первого дня: репозиторий в вашем GitHub, не у нас. Доступы к инфраструктуре — на вас. Документация (архитектура, API, схема базы, схема интеграций, схема деплоя) — в репозитории, обновляется вместе с кодом. Уйдёте от нас — заберёте систему целиком, без блокирующих доступов и «только наш инженер знает, как это работает».

Архитектурный спринт — 5 дней. Lean MVP-backend — 6–8 недель до прода. Production-backend для платформы — 10–14 недель до прода. Backend для готового фронта — 6–10 недель. Стабилизация — 4–8 недель. Первый рабочий backend-slice на staging обычно появляется через 3–4 недели после спринта и доступа к окружениям.

Начните с архитектурного спринта (тариф 030-A) или backend-аудита (030-B). За 5–7 дней получите карту продукта или существующей системы, список рисков с приоритетом, понятный план работ и точную смету. После этого решите, нужен ли вам backend целиком, стабилизация существующего или совсем другой формат работ.