Backend-разработчик: вопросы и ответы для собеседования

Образец ответа

Я начинаю с сценариев потребления: кто вызывает API, какие данные нужны, какие ошибки критичны и какие поля должны быть стабильными. Затем проектирую ресурсные и предсказуемые endpoints, заранее закладываю версионирование, единый формат ошибок и понятные правила пагинации. По возможности делаю изменения additive, чтобы не ломать клиентов. Также сразу думаю про idempotency для повторных запросов, rate limiting и валидацию входных данных.

Образец ответа

Однажды endpoint начал регулярно уходить в timeout под нагрузкой. Я посмотрел метрики, логи и trace'ы в APM и увидел классический N+1: внутри цикла выполнялись десятки мелких запросов к базе. Я переписал запрос на batched-выборку, добавил нужный index и сократил число обращений к БД. В результате latency упала с секунд до десятков миллисекунд, а timeouts исчезли.

Образец ответа

Сначала я выясняю, действительно ли нужна строгая consistency, или бизнес допускает eventual consistency. Если операция проходит через несколько сервисов, я избегаю distributed transactions и чаще использую saga с compensating actions либо outbox-паттерн для надёжной публикации событий. Для повторных вызовов делаю операции idempotent, чтобы retries не создавали дубликаты. Там, где возможны расхождения, добавляю reconciliation jobs и наблюдение за расхождениями.

Образец ответа

Для меня безопасность начинается с того, что ни один endpoint не доверяет входным данным клиента. Я использую authentication и authorization на каждом уровне, параметризованные запросы, защиту от injection, хранение секретов в защищённом хранилище, а не в коде, и принцип least privilege для сервисных аккаунтов. Для чувствительных операций добавляю audit logging и rate limiting. Отдельно слежу за зависимостями и патчами, потому что уязвимости часто приходят через них.

Образец ответа

Я разделяю ожидаемые ошибки и неожиданные сбои. Ожидаемые ошибки обрабатываю понятными ответами для клиента, а неожиданные логирую с контекстом, который поможет быстро восстановить цепочку событий. Использую structured logs, metrics и traces, чтобы видеть latency, error rate и узкие места. Алерты настраиваю по симптомам, которые чувствует пользователь, а не по шумным внутренним метрикам. Это помогает ловить инциденты до того, как они станут заметны клиентам.

ACID — это Atomicity, Consistency, Isolation и Durability. Atomicity означает, что транзакция либо выполняется целиком, либо откатывается целиком. Consistency сохраняет корректность состояния данных. Isolation защищает параллельные транзакции от взаимного влияния. Durability гарантирует, что после commit данные не потеряются при сбое.

Очередь сообщений полезна, когда нужно развязать producer и consumer, переживать всплески нагрузки и выполнять работу асинхронно. Она помогает, если consumer может быть временно недоступен или если обработка тяжёлая и не должна блокировать пользователя. Прямой вызов уместен, когда нужен немедленный ответ и допустима более жёсткая связность между сервисами.

Pessimistic locking блокирует запись уже в момент чтения или изменения, чтобы никто другой не мог её поменять до release lock. Это уменьшает конфликты, но может снижать throughput. Optimistic locking предполагает, что конфликтов немного: при записи проверяется version или timestamp, и если запись изменилась, операция отклоняется. Обычно optimistic locking лучше для read-heavy систем.

Caching снижает latency и уменьшает нагрузку на источник данных, потому что часто запрашиваемая информация хранится ближе к потребителю. Основной риск — stale data и сложность invalidation, которая действительно часто бывает самой трудной частью. Обычно помогают TTL, cache-aside или write-through в зависимости от требований к consistency, а также аккуратная инвалидация при записи.

Idempotent операция даёт тот же итог при одном выполнении и при нескольких повторениях. Это особенно важно, потому что сети ненадёжны, клиенты retry'ят запросы, а пользователь может нажать кнопку дважды. Без idempotency можно случайно создать дубликаты, двойные списания или повторные изменения состояния. Для защиты часто используют idempotency keys.

Однажды я запустил migration, которая добавляла NOT NULL column без default на большой таблице. Это вызвало lock и начало блокировать записи. Я остановил миграцию, чтобы быстро снять блокировку и восстановить сервис, а затем переделал процесс: сначала добавил колонку nullable, потом backfill в батчах и только после этого ввёл constraint. После инцидента мы внедрили чек-лист безопасных миграций.

Однажды маркетинговая кампания дала примерно в десять раз больше обычного трафика, и сервис начал терять запросы. Я быстро масштабировал stateless-инстансы, включил короткий cache на самом горячем read-endpoint и добавил rate limiting, чтобы защитить базу. После стабилизации мы провели нагрузочное тестирование под подобный сценарий, чтобы он больше не был сюрпризом.

У нас был payment provider, у которого документация была неполной и местами неточной. Я поднял sandbox harness, чтобы проверить реальное поведение, и зафиксировал фактические ответы сервиса. Затем я завернул интеграцию в собственный adapter, чтобы все особенности провайдера были изолированы в одном месте. Это позволило быстро выпустить релиз и упростило будущие изменения.

В одном проекте сервис был избыточно выделен по ресурсам, а база данных была самой дорогой статьёй. Я проанализировал запросы, добавил недостающие indexes и перенёс холодные данные в более дешёвое хранилище. Затем я right-sized инфраструктуру по реальным метрикам использования, а не по ощущениям. В итоге ежемесячные расходы снизились примерно на треть без ухудшения latency.