Backend сайта — запросы, бизнес-правила и ответы сервера

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

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

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

Backend начинается там, где интерфейс больше не имеет права верить самому себе.

Пользователь нажимает «Сохранить адрес». Браузер собирает данные и отправляет запрос. Дальше серверная часть выполняет цепочку:

Публикация статьи может завершиться одной транзакцией в базе. Оплата заказа связывает корзину, цену, остаток, платёжный сервис, чек и уведомления. Создание заявки может требовать CRM, назначения менеджера и защиты от дубля.

HTTP даёт общую модель запроса и ответа: метод, адрес, заголовки, содержимое и статус. Но бизнес-смысл команда задаёт сама. Ответ 200 OK говорит об успешной обработке в рамках выбранного метода и контракта. Он не доказывает неописанные внешние результаты: зачисление денег, приём заказа складом или появление сделки в CRM нужно выражать состоянием операции и проверять отдельно.

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

Бизнес-логика отвечает на вопросы:

Фраза «назначить подходящего менеджера» не является правилом. Нужно определить признаки: регион, продукт, тип клиента, загрузка, рабочее время, приоритет и действие, если никто не подходит. «Рассчитать скидку» также недостаточно без источника цены, последовательности скидок, округления и даты действия.

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

Список экранов описывает поверхность продукта. Стоимость backend скрыта в правилах, данных, ролях и исключениях.

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

В интерфейсе можно скрыть административную кнопку от обычного пользователя. Это полезно: человек не видит лишнего действия. Но запрос можно повторить вручную, изменить идентификатор объекта или отправить из другой программы.

Поэтому сервер проверяет право на каждое защищённое действие. Недостаточно установить, что пользователь вошёл. Нужно убедиться, что ему разрешено изменить именно этот заказ, скачать именно этот файл или назначить именно эту роль.

Аутентификация отвечает на вопрос «кто обращается?». Авторизация — «что этому субъекту разрешено?». Пользователь может успешно пройти вход, но не иметь доступа к документам другого юридического лица. Технический сервис может иметь валидный ключ, но только право создавать заявки, а не читать всю клиентскую базу.

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

Спрятанная кнопка — решение интерфейса. Серверная проверка полномочий — решение безопасности.

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

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

Полезно зафиксировать для каждого объекта:

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

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

Сеть ненадёжна. Пользователь нажал кнопку, сервер завершил операцию, но ответ потерялся. Браузер повторил запрос. Если backend воспринимает повтор как новое действие, появляются два заказа или два списания.

По RFC 9110 метод идемпотентен, если предполагаемый эффект нескольких одинаковых запросов на сервер совпадает с эффектом одного; отдельные записи в логах при этом могут появляться для каждой попытки. Все безопасные методы, включая GET и HEAD, идемпотентны; PUT и DELETE тоже идемпотентны, хотя не считаются безопасными. Неидемпотентный запрос нельзя автоматически повторять без знания, что его семантика сделана идемпотентной, или что первая попытка не была применена.

Для критичного POST распространён отдельный ключ идемпотентности. Но одно наличие заголовка не даёт гарантии: контракт должен определить область уникальности, связь ключа с телом запроса, конкурентные повторы, срок хранения и ответ на повтор. Idempotency-Key на дату проверки описан IETF как Internet-Draft, поэтому клиент не может считать его универсально поддержанным без документации конкретного API.

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

Транзакция помогает объединить связанные изменения в пределах поддерживаемой транзакционной границы. Если заказ создан, но его строки не сохранились, система не должна объявлять полупустой результат успешным. Однако одна транзакция базы не охватывает внешний платёж или CRM. Для распределённого процесса нужны явные статусы и повторяемые шаги; компенсация, например отмена резерва после неуспешной оплаты, остаётся отдельной операцией, которая тоже может завершиться ошибкой и не равна атомарному откату.

После создания заказа письмо, обновление CRM, документ и аналитику можно выполнить отдельно от ответа пользователю.

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

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

Для пользователя важно, какой шаг уже завершён. Сообщение «заказ принят» допустимо после надёжной записи заказа, даже если письмо придёт позже. Сообщение «оплата прошла» нельзя показывать только потому, что запрос отправлен провайдеру.

API задаёт доступные операции, адреса, параметры, схемы данных, способы авторизации и ответы. OpenAPI позволяет формально описать HTTP-интерфейс. Это помогает frontend и внешним интеграторам договориться, не раскрывая внутреннюю реализацию. Отдельно нужно договориться, как сервер сообщает об отсутствии ресурса: статья об ошибке 404 Not Found разбирает, когда вернуть страницу, редирект или честный отказ.

Контракт должен включать ошибки. Если сервер вернул только «что-то пошло не так», интерфейс не понимает, просить ли пользователя исправить поле, войти снова или повторить действие позже. При этом наружу нельзя отдавать секреты, SQL-запросы и внутренние пути.

HTTP-статус выбирают по семантике результата, а не по удобству одного обработчика. Например, 401 относится к отсутствующим или неподходящим учётным данным, 403 — к отказу выполнить понятый запрос, 404 — к отсутствию текущего представления ресурса, а 409 может описывать конфликт с его текущим состоянием. Конкретный API должен документировать, какие доменные ошибки соответствуют этим статусам и можно ли повторять запрос; сам код не доказывает, что повтор безопасен.

Версия контракта нужна, когда меняется смысл или структура. Добавление необязательного поля обычно совместимо. Удаление поля, изменение типа или новая трактовка статуса может сломать клиента. План совместимости важнее красивого номера версии.

Backend может кэшировать результат тяжёлого запроса, страницу, каталог или разрешения. Это снижает нагрузку и время ответа. Цена — риск показать старое состояние.

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

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

Для каждого кэша до реализации достаточно назвать:

Система может вернуть красивый экран и потерять следующий шаг. Заявка записалась на сайте, но не попала в CRM. Заказ создан, но фоновая задача не обновила остаток. Без наблюдаемости команда узнаёт о проблеме от клиента.

Наблюдаемость складывается из нескольких сигналов:

Технический request_id помогает связать записи одного обращения, если его проверяют и последовательно передают между компонентами. Бизнес-идентификатор заказа или заявки позволяет сверить системы. Пароли, токены, ключи шифрования, строки подключения, платёжные данные и чувствительные персональные сведения обычно не записывают напрямую: необходимые значения удаляют, маскируют, хешируют или шифруют, а доступ и срок хранения журналов ограничивают по назначению.

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

Фраза «делаем бэкапы» не доказывает восстановимость. Нужно знать:

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

Целевое время восстановления и допустимая потеря данных формулируют как RTO и RPO вместе с владельцем процесса. Это цели проектирования, а не обещание фактического результата. Новостной раздел и очередь оплаченных заказов имеют разную критичность; достижимость целей подтверждают учениями восстановления, включая зависимости, целостность данных и время возврата сервиса.

Возьмите одну критичную операцию и заполните карточку.

Для заявки это может быть маршрут «форма — запись — CRM — назначение — уведомление». Для заказа добавятся цена, остаток, оплата и возврат. Такой паспорт помогает составить техническое задание и оценить реальный объём лучше списка страниц.

Backend превращает действие в проверенный и сохранённый бизнес-результат. Он применяет правила, защищает объекты, управляет состояниями, выполняет повторы, связывает системы и оставляет доказательства работы.

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

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