# Backend Engineering

> Реализовать или переработать серверное поведение в сервисах, фоновых заданиях, интеграциях или предметной логике. Применять для изменений кода и поведения при сбоях; решения по контракту относятся к проектированию API, запрос только на проверку — к review кода.

- Skill: `fbakiyev/backend-engineering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/backend-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/backend-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/backend-engineering

---


# Backend-разработка

## Найти инвариант

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

## Решения при реализации

- Обеспечивай инварианты конкурентного выполнения там, где находится общее состояние. Проверка с последующей незащищённой записью допускает гонку; локальная блокировка процесса не защищает другой процесс. Выбирай транзакцию, ограничение, условную запись или существующий механизм координации с учётом реальной модели развёртывания.
- По возможности помещай дедупликацию и защищаемый ею сохраняемый эффект в одну атомарную границу. Между базой данных, очередью и внешним провайдером учитывай сбой между двумя операциями через принятый в проекте механизм восстановления или сверки. Один кеш запросов не доказывает однократность выполнения.
- Назначь компонент, управляющий повторами, и общий срок или бюджет попыток. Повторяй только те ошибки, исход и повторяемость которых это допускают; вложенные повторы умножают нагрузку. Таймаут или отмена не доказывают, что удалённый побочный эффект не произошёл.
- Для фоновой работы определи момент подтверждения и поведение после частичного выполнения. Повторное воспроизведение не должно пропускать незавершённую работу или повторять уже выполненный эффект. Контрольные точки и состояния прогресса должны описывать восстановление, а не только обновления успешного пути.
- Проверяй полномочия относительно затрагиваемого ресурса, а не только наличие авторизованного пользователя. Сохраняй принятую серверную валидацию и публичные ответы, даже если новый клиент уже проверяет входные данные.

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

## Результат и проверка

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

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

Верни описание изменённого поведения, результаты проверки и существенные ограничения восстановления или внедрения. ADR нужен только для значимого архитектурного решения, передача контекста — только для запрошенной записи или реальной передачи работы. Шаблоны репозитория необязательны и применяются при наличии.