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