Вопросы на собеседовании: Бэкенд-разработчик

Держите URL мелкими и подгружайте глубокие связи отдельно.

• Вкладывайте только на один уровень, например /orders/{id}/items, избегая /users/{id}/orders/{id}/items.
• Для более глубоких связей возвращайте идентификаторы связанных ресурсов и давайте клиенту грузить их отдельно.
• Или предложите параметр ?include=, инициирующий JOIN на стороне сервера.
• Определите соглашения по именованию, методам и структуре ошибок до первого эндпоинта.

Проблема N+1: один запрос на N записей плюс ещё по запросу на каждую запись.

• В итоге выходит N+1 запросов вместо одного.
• В ORM решается жадной загрузкой через JOIN-включения или пакетный загрузчик вроде DataLoader.
• В сыром SQL перепишите как один запрос с JOIN или IN, а затем соберите результат в коде.

Различие в том, блокируете ли вы строку заранее.

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

Выбирайте документоориентированную базу, когда данные естественно иерархичны или полиморфны.

• Хорошо подходит для вложенных или полиморфных структур, требующих в SQL множества JOIN-таблиц.
• Также когда схема быстро меняется и добавление столбцов в общую таблицу было бы разрушительным.
• Реляционная выигрывает для многострочных ACID-транзакций, сложных произвольных запросов и строгой ссылочной целостности.
• Решение зависит от паттернов доступа, а не только от формы данных.

Используйте присланный клиентом Idempotency-Key для дедупликации запросов.

• Клиент генерирует уникальный ключ, обычно UUID, и отправляет его с запросом.
• Сервер сохраняет ключ и ответ в кратковременном кеше вроде Redis перед обработкой.
• При повторном ключе возвращает кешированный ответ, не выполняя побочный эффект.
• Установите TTL, обычно 24 часа, и задокументируйте окно повторных попыток клиента.

Пул соединений переиспользует открытые соединения с базой между запросами.

• Это избегает нового TCP-соединения и TLS-рукопожатия на каждый запрос.
• Без него сервис под нагрузкой может исчерпать лимиты соединений и добавить сотни мс на запрос.
• Настраивайте минимальный и максимальный размер пула по конкурентности, max_connections базы и среднему времени запроса.

Подтвердите утечку, затем снимайте хип, чтобы найти удерживаемое.

• Подтвердите по метрике использования хипа, которая растёт вместо возврата к базовому уровню после GC.
• Делайте снимки хипа во времени через --inspect и Chrome DevTools или clinic.js, затем сравнивайте их.
• Ищите неудалённые слушатели событий, замыкания с большими буферами и неограниченные кеши на уровне модуля.

Circuit breaker отслеживает частоту ошибок зависимости и быстро падает при их всплеске.

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

B-tree индекс даёт поиск за O(log n), но добавляет стоимость записи.

• Он хранит отсортированные ключи в сбалансированном дереве, находя строки за O(log n) вместо полного сканирования.
• Он ускоряет чтение, но замедляет каждый INSERT, UPDATE и DELETE, так как обновляется и дерево.
• Добавляйте, когда планы показывают последовательное сканирование больших таблиц с избирательными фильтрами.
• Проверяйте неиспользуемые индексы через pg_stat_user_indexes и удаляйте лишние.

CAP утверждает, что распределённое хранилище гарантирует не более двух из трёх: согласованность, доступность и устойчивость к разделению.

• Разделения неизбежны, поэтому реальный выбор между CP и AP.
• Пример CP: PostgreSQL с синхронной репликацией.
• Пример AP: Cassandra или DynamoDB.
• Используйте это, чтобы решить, терпит ли сервис устаревшие чтения или нуждается в линеаризуемых.

Используйте паттерн expand-contract для изменений схемы без простоя.

• Сначала деплойте миграцию, добавляющую новые столбцы или таблицы без удаления старых.
• Деплойте код, который пишет и в старую, и в новую структуру.
• Заполните существующие данные, затем деплойте финальную миграцию, удаляющую старую структуру.
• Избегайте блокирующего DDL, используя concurrent index builds в PostgreSQL.

Вертикальное добавляет ресурсы одной машине; горизонтальное добавляет экземпляры.

• Вертикальное добавляет CPU или RAM одной машине: просто, но ограниченно и создаёт единую точку отказа.
• Горизонтальное добавляет экземпляры за балансировщиком, требуя stateless-приложений или вынесенного состояния.
• По умолчанию выбирайте горизонтальное для stateless API-сервисов.
• Принимайте вертикальное для управляемых баз, пока не нужны read replicas или шардирование.

Event sourcing хранит состояние как упорядоченный лог неизменяемых событий.

• Текущее состояние получается воспроизведением событий с начала или со снимка.
• Подходит, когда нужен полный аудит, воспроизведение истории или несколько read-моделей.
• Стоимость: сложные read-пути, итоговая согласованность между проекциями и больше хранилища.

Используйте token bucket или скользящее окно в Redis с ключом по клиенту.

• Ключ по API-ключу или IP-адресу.
• На каждый запрос атомарно уменьшайте счётчик и проверяйте лимит, возвращая 429 с Retry-After при превышении.
• Настраивайте лимиты на ключ для разных уровней клиентов и отдавайте X-RateLimit-Remaining.
• Рассмотрите вынос логики на уровень шлюза, чтобы код сервиса оставался чистым.

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

• Запросите pg_locks и pg_stat_activity или лог ошибок, чтобы увидеть, кто держит и ждёт что.
• Дедлоки обычно возникают из-за захвата блокировок в разном порядке.
• Исправьте, захватывая блокировки в согласованном порядке, часто сортируя идентификаторы ресурсов заранее.
• Установите разумный lock_timeout, чтобы зависшая транзакция быстро падала.

Держите транзакции локальными и используйте саги между сервисами.

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

Очередь доставляет сообщение одному потребителю; pub-sub рассылает всем подписчикам.

• Очередь: один потребитель забирает сообщение, и оно удаляется, хорошо для распределения работы.
• Pub-sub: каждый текущий подписчик получает сообщение, хорошо для широковещания событий.
• Kafka размывает границу: группы потребителей ведут себя как очереди, независимые группы воспроизводят тот же лог.
• Выбирайте по тому, обрабатывается ли сообщение один раз или многими независимыми системами.

Используйте stateless JWT для аутентификации и проверки в middleware для авторизации.

• Выдавайте короткий access-токен и долгий refresh-токен при входе; передавайте access-токен в Authorization.
• Храните роли или детальные разрешения в базе и проверяйте их в middleware до обработчика.
• Держите логику auth отдельно от бизнес-логики.
• Ротируйте ключи подписи, ставьте строгий срок действия и используйте HTTPS, чтобы предотвратить кражу токенов.

Денормализация хранит избыточные данные, чтобы избежать дорогих JOIN.

• Пример: копировать отображаемое имя пользователя в таблицу заказов.
• Помогает, когда read-heavy эндпоинт делает один и тот же JOIN миллионы раз.
• Компромисс: обновления нужно распространять на копии, добавляя сложность записи и риск устаревания.
• Вводите только после того, как профилирование подтвердит, что JOIN реально узкое место.

Кешируйте данные, которые дороги, меняются редко и читаются куда чаще, чем пишутся.

• Кешируйте на слое, ближайшем к потребителю.
• Для разделяемых между экземплярами данных используйте Redis с явным TTL и инвалидацией при записи.
• Защищайтесь от cache stampede вероятностным досрочным истечением или мьютексом при холодном кеше.
• Делайте ключи узкими и для простых случаев предпочитайте TTL-истечение событийной инвалидации.