Архитектура кастомной CRM-системы

Архитектура CRM определяет не только скорость интерфейса. От нее зависит, сможет ли система безопасно хранить клиентские данные, переживать рост нагрузки, подключать новые каналы продаж и изменяться вместе с процессами компании.

В этой статье разберем техническую сторону: как разделить frontend и backend CRM, когда выбирать Node.js, где нужен брокер сообщений и в каких случаях микросервисы создают больше проблем, чем пользы. Если вам нужна оценка готового проекта, а не только выбор технологий, посмотрите условия разработки кастомной CRM-системы.

С чего начинается архитектура CRM

Выбор фреймворка не должен быть первым решением. Сначала команда фиксирует:

• роли пользователей и ограничения доступа;
• основные сущности: лид, клиент, сделка, объект, заказ, счет, документ;
• жизненный цикл каждой сущности и допустимые переходы между статусами;
• автоматические действия, уведомления и фоновые задачи;
• источники данных и внешние системы;
• требования к времени ответа, доступности и восстановлению после сбоя;
• прогноз по количеству пользователей, записей и операций.

Эти данные превращаются в модель предметной области и карту интеграций. Подробный порядок сбора требований описан в руководстве по проектированию CRM.

Модульный монолит или микросервисная CRM

Модульный монолит

Для первого релиза CRM модульный монолит часто практичнее микросервисов. Система развертывается как одно приложение, но код разделен на независимые модули: клиенты, сделки, задачи, документы, уведомления, аналитика и интеграции.

Преимущества подхода:

• проще разработка, тестирование и развертывание;
• транзакции между связанными сущностями остаются предсказуемыми;
• меньше инфраструктурных расходов;
• быстрее выпуск MVP и проверка процессов на реальных пользователях.

Главное условие — не смешивать модули через общие таблицы и случайные вызовы. У каждого модуля должны быть понятные границы и публичные интерфейсы.

Микросервисы

Микросервисная архитектура оправдана, когда отдельные части системы имеют разную нагрузку, выпускаются независимыми командами или требуют изоляции. Например, обработка звонков, генерация документов, импорт крупных фидов и BI-аналитика могут масштабироваться отдельно от основной CRM.

Но за независимость приходится платить:

• появляется распределенная трассировка и сложная диагностика;
• данные между сервисами становятся согласованными не мгновенно;
• нужны очереди, повторная доставка событий и защита от дублей;
• усложняются DevOps, тестовые среды и контроль версий API.

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

Backend CRM: Node.js, Python, PHP или Go

Язык backend выбирают по нагрузке, компетенциям команды и экосистеме интеграций.

Node.js и TypeScript

Node.js подходит для CRM с большим количеством сетевых операций: API, WebSocket, телефония, чаты, уведомления и обмен с внешними сервисами. TypeScript помогает формализовать контракты данных между frontend и backend. Для структурированного приложения часто используют NestJS, для компактных сервисов — Fastify или Express.

Python

Python удобен, когда CRM тесно связана с аналитикой, обработкой документов, машинным обучением или AI-модулями. Django дает готовую административную часть и ORM, FastAPI подходит для API и отдельных сервисов.

PHP

Laravel и Symfony остаются рациональным выбором для бизнес-систем, особенно если у компании уже есть PHP-команда или интеграции с сайтом и 1С-Битрикс. Качество архитектуры зависит не от языка, а от границ модулей, модели данных, тестов и процесса разработки.

Go

Go уместен для сервисов с высокой конкуренцией запросов, потоковой обработкой и строгими требованиями к потреблению ресурсов. Использовать его для всей CRM необязательно: часто достаточно выделить на Go один нагруженный компонент.

База данных и модель хранения

Для основной транзакционной модели CRM обычно подходит PostgreSQL. Реляционная база обеспечивает ограничения целостности, транзакции, индексы, полнотекстовый поиск и работу с JSON-полями.

Дополнительные хранилища подключают под конкретную задачу:

• Redis — кэш, блокировки, временные данные и очереди небольшого масштаба;
• OpenSearch или Elasticsearch — сложный поиск по большой базе;
• ClickHouse — события и аналитические срезы;
• S3-совместимое хранилище — документы, записи звонков и вложения;
• векторная база — семантический поиск и RAG по документам компании.

Не стоит переносить все данные в специализированные хранилища. Карточка клиента, сделка и платеж должны иметь один надежный источник истины.

API и интеграции CRM

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

REST API подходит для большинства синхронных операций. Webhook сообщает о событии без постоянного опроса. Очередь нужна, если операция выполняется долго или внешняя система может быть временно недоступна.

Особое внимание требуется интеграциям с:

• 1С и ERP;
• сайтом и формами заявок;
• IP-телефонией;
• почтой и мессенджерами;
• платежными сервисами;
• рекламными кабинетами и сквозной аналитикой.

Для защиты от дублей обработчики событий делают идемпотентными: повторная доставка одного события не должна создавать вторую сделку или повторно проводить оплату.

Frontend CRM: интерфейс рабочего инструмента

Менеджер может проводить в CRM весь рабочий день, поэтому frontend влияет на производительность не меньше backend. React, Next.js, Vue и Nuxt позволяют строить динамические интерфейсы, но выбор библиотеки сам по себе не решает UX-задачи.

Важнее обеспечить:

• быстрый поиск и открытие карточки;
• сохранение черновиков и защиту от потери данных;
• виртуализацию длинных таблиц;
• понятные состояния загрузки и ошибки;
• клавиатурную навигацию;
• адаптацию критичных сценариев под планшет и телефон;
• обновления через WebSocket там, где действительно нужен real-time.

Например, в кейсе SPA Booking & CRM System синхронизация через Node.js и сокеты использовалась для мгновенного обновления бронирований у сотрудников ресепшн. Это конкретная бизнес-задача, а не технология ради технологии.

Безопасность CRM

CRM содержит персональные данные, историю коммуникаций и коммерческую информацию. Базовый контур безопасности включает:

• ролевую модель и принцип минимальных полномочий;
• MFA для сотрудников с расширенным доступом;
• шифрование соединений и секретов;
• журналирование действий с чувствительными данными;
• резервное копирование и регулярную проверку восстановления;
• ограничение и ротацию ключей внешних интеграций;
• отдельные production, staging и development среды;
• контроль выгрузок и массовых операций.

Требования ФЗ-152, GDPR и внутренних политик нужно учитывать до выбора места размещения и схемы резервного копирования.

Как выбрать технологический стек CRM

Практический алгоритм выглядит так:

1. Описать роли, процессы, сущности и интеграции.
2. Определить нефункциональные требования: нагрузку, доступность, безопасность и сроки восстановления.
3. Выбрать минимальную архитектуру, которая закрывает эти требования.
4. Проверить, сможет ли текущая команда поддерживать выбранный стек.
5. Зафиксировать границы модулей и контракты API.
6. Создать прототип наиболее рискованных интеграций.
7. Запустить первый полезный контур и проверить его на реальных пользователях.

Для большинства CRM разумная стартовая точка — модульный монолит, PostgreSQL, документированное API, очередь фоновых задач и отдельные сервисы только для действительно независимых или нагруженных функций.

FAQ

Обязательно ли строить CRM на микросервисах?

Нет. Микросервисы нужны при доказанной необходимости независимого масштабирования, развертывания или изоляции. Для MVP и систем среднего масштаба модульный монолит обычно проще и надежнее.

Подходит ли Node.js для backend CRM?

Да, особенно для API, WebSocket и большого количества интеграций. Но выбор нужно соотносить с компетенциями команды, требованиями к данным и существующей инфраструктурой.

Какую базу данных выбрать для CRM?

PostgreSQL закрывает большинство транзакционных задач CRM. Поиск, аналитика и семантическая обработка могут использовать дополнительные специализированные хранилища.

Когда архитектуру нужно пересматривать?

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

Итог

Хорошая архитектура кастомной CRM начинается с процессов и требований, а не со списка модных технологий. Backend, frontend, база данных и интеграции должны образовывать систему, которую команда может безопасно развивать после первого релиза.

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