Backend

Что такое серверная разработка

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

• Цель — предоставить надёжный и быстрый доступ к ресурсам и операциям: от простого чтения данных до сложных транзакций.

• Сервер — «источник истины»: хранит и валидирует состояние, управляет побочными эффектами (отправка писем, списание средств, очереди задач).

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

Какие задачи решает сервер

• Транспорт: принятие соединений, парсинг протокола (HTTP/2, HTTP/3, gRPC, GraphQL-over-HTTP, WebSocket), формирование ответов.

• Бизнес-логика: правила, валидация, расчёты, агрегирование данных.

• Доступ к данным: чтение/запись в базы данных, кэши, файловые и объектные хранилища.

• Интеграции: взаимодействие с внешними сервисами (платёжки, почта, сторонние API).

• Безопасность: аутентификация, авторизация, шифрование, аудит.

• Надёжность: обработка ошибок, ретраи, идемпотентность, очереди, дедупликация.

• Масштабирование: горизонтальное и вертикальное, балансировка, разделение нагрузки, очереди и стримы.

• Наблюдаемость: логи, метрики, трассировки, алёрты.

• Операции: конфигурация, миграции схемы данных, деплой, откаты.

Жизненный цикл запроса

Любой протокол сводится к последовательности шагов: принять запрос, проверить, преобразовать, выполнить действие, вернуть ответ и записать следы.

• Приём: чтение заголовков, тела, ограничение размеров и времени.

• Аутентификация: установление личности (токен, ключ, сертификат).

• Авторизация: проверка прав на конкретное действие и ресурс.

• Валидация: проверка формата и семантики входных данных.

• Бизнес-операция: вызов доменных служб, транзакции, взаимодействие с БД и очередями.

• Формирование ответа: правильный статус/код ошибки, заголовки, сериализация.

• Наблюдаемость: лог, метрики, трассировка с корреляционным ID.

Состояние: статeless vs stateful

Stateless сервер не хранит сессию между запросами — все данные приходят в каждом запросе. Stateful сервер хранит часть состояния (сессии, подписки, сокеты).

• Stateless проще масштабировать и балансировать: любой узел может обработать любой запрос.

• Stateful нужен для длительных соединений, очередей, игр, realtime; требует прилипания сессий или внешнего хранилища состояния.

Модель исполнения: конкурентность и ввод-вывод

Серверы в основном связаны с ожиданием ввода-вывода (I/O). Существует два подхода: асинхронный неблокирующий (event loop, реактивные потоки) и многопоточный (thread-per-request, пул потоков).

• Асинхронный стиль масштабируется при большом числе параллельных I/O-операций.

• Потоки проще для CPU-связанной логики, но дороже по памяти и переключениям контекста.

Данные и хранение

Сервер управляет данными через слой абстракции к хранилищам.

• Реляционные БД: строгие схемы, транзакции, JOIN; хороши для критичных инвариантов.

• NoSQL: документо- и ключ-значение хранилища для больших объёмов и гибких схем.

• Кэш: Redis/Memcached для низкой задержки чтения горячих данных.

• Очереди/стримы: брокеры сообщений для асинхронной обработки и интеграций.

• Файлы/объекты: блобы в объектных хранилищах, CDN для раздачи.

Проектирование интерфейсов (API)

API — контракт между сервером и потребителями (веб, мобильные клиенты, другие сервисы).

• Ясные ресурсы и операции: предсказуемые пути, семантика методов, коды статуса.

• Стабильные схемы: версионирование, обратная совместимость, депрекейшн-план.

• Ошибки: единый формат, коды, поля code, message, details.

• Пагинация/фильтры: limit/offset или курсоры; предсказуемые ответы.

Безопасность по умолчанию

• Аутентификация: токены, mTLS, ключи; минимальный набор прав по принципу наименьших привилегий.

• Авторизация: роли/политики (RBAC/ABAC); проверка на каждом действии.

• Валидация: типы, длины, форматы, допустимые диапазоны.

• Защита транспорта: HTTPS/TLS, HSTS, современные шифры.

• Секреты: хранилища секретов, ротация ключей, минимизация экспозиции.

• Входные лимиты: ограничение размеров тела, rate limiting, captcha для публичных форм.

• Журналы аудита: кто, что, когда и откуда сделал с чувствительными объектами.

Надёжность: ошибки, ретраи, идемпотентность

Сбои — норма в распределённых системах. Сервер обязан корректно их переживать.

• Классификация ошибок: клиентские (4xx) vs серверные (5xx); временные vs постоянные.

• Ретраи: экспоненциальная задержка, джиттер; только для идемпотентных или с ключами Idempotency-Key.

• Компенсации: саги и обратные действия при частичных отказах.

• Очереди: повторная обработка, dead-letter очереди, лимиты попыток.

Производительность и масштабирование

• Кэширование: результаты запросов, агрегаты, метаданные; стратегия инвалидации.

• Пулы соединений: к БД и внешним сервисам; таймауты и лимиты.

• Профилирование: горячие точки CPU/I-O, медленные запросы, индексы.

• Горизонтальное масштабирование: несколько экземпляров за балансировщиком.

• Разделение нагрузки: очереди, шедулеры, бэкграунд-джобы.

Наблюдаемость: логи, метрики, трассировки

Нельзя управлять тем, чего не видишь.

• Логи: структурированные, с уровнями (info/warn/error), кореляционными ID, полями запроса/ответа.

• Метрики: счётчики, таймеры, гистограммы (RPS, p95, ошибки, использование памяти/CPU).

• Трассировки: распределённые спаны между сервисами, контекст передаётся заголовками.

• Алёрты: SLO/SLA, пороги и уведомления, дашборды.

Конфигурация и миграции

• Конфиги из окружения: без хардкода; валидация при старте.

• Миграции БД: версионирование схемы, идемпотентные апдейты, откаты.

• Фичефлаги: поэтапный rollout, A/B-тесты, тёмные релизы.

Тестирование и качество

• Юнит-тесты: проверяют чистые функции/правила домена.

• Интеграционные: взаимодействие слоёв, БД, очереди.

• E2E: полный путь запроса; контракты с внешними API (consumer-driven contracts).

• Нагрузочные: производительность и деградации под давлением.

• Безопасность: статический анализ, fuzzing, негативные сценарии.

Организация кода без привязки к фреймворку

Структура следует от домена и потоков данных. Модули должны быть слабо связаны и иметь чёткие интерфейсы.

Краткий чек-лист начинающего бэкенд-разработчика

• Понимай жизненный цикл запроса и расставляй обязательные «рамки»: аутентификация → авторизация → валидация → бизнес-операция → ответ → следы.

• Проектируй API как контракт: стабильность, ошибки, версия, пагинация.

• Думай о данных: транзакции, индексы, миграции, резервные копии.

• Закладывай надёжность: ретраи, идемпотентность, очереди, таймауты, лимиты.

• Масштабируй осознанно: измеряй, кэшируй, разделяй нагрузку.

• Делай систему наблюдаемой: логи, метрики, трассировки и алёрты.

• Автоматизируй тесты и деплой; береги секреты.