Разбор сложных вопросов по REST, gRPC и архитектуре бэкенда. Идемпотентность, кэширование и распределенные транзакции для Middle/Senior.
На собеседованиях уровня Senior в 2026 году редко спрашивают разницу между PUT и PATCH. Вместо этого интервьюеры проверяют понимание семантики и пограничных случаев. Один из популярных вопросов — обеспечение идемпотентности для не-идемпотентных методов.
Если клиент отправляет запрос POST на создание заказа, но не получает ответ из-за сетевого сбоя, повторный запрос может привести к дубликату. Стандартное решение — использование Idempotency-Key в заголовках. На стороне сервера необходимо реализовать проверку этого ключа в кэше (например, Redis) перед выполнением бизнес-логики. Срок жизни ключа обычно составляет 24 часа.
В 2026 году индустрия отошла от версионирования через URL (v1/v2) в пользу Header Versioning или Content Negotiation. Это позволяет сохранять чистоту ресурсов, но усложняет кэширование на уровне CDN. При обсуждении этой темы важно упомянуть Sunset Header (RFC 8594), который информирует клиентов о скором выводе версии из эксплуатации.
Интервьюеры часто копают вглубь механизмов инвалидации. Основная проблема — Race Condition при обновлении кэша. Стоит разобрать паттерн Cache-Aside и проблемы «собачьей свалки» (Thundering Herd), когда при истечении срока жизни популярного ключа сотни запросов одновременно бьют в базу данных. Решение — использование Soft TTL и вероятностного пересчета или использование блокировок (Distributed Locks).
Поскольку к 2026 году HTTP/3 стал стандартом де-факто для высоконагруженных систем, на бэкенд-собеседованиях спрашивают, как QUIC решает проблему Head-of-Line Blocking, характерную для TCP. Нужно понимать, что в HTTP/3 потеря одного пакета блокирует только один поток (stream), а не всё соединение целиком, что критично для мобильных сетей и API с большим количеством мелких запросов.
Когда REST-запрос затрагивает несколько микросервисов, классический ACID не работает. На собеседованиях ждут разбора паттерна Saga. Существует два подхода: Оркестрация (центральный контроллер) и Хореография (событийная модель). Для уровня Senior важно уметь объяснить, как реализовывать компенсирующие транзакции: что делать, если третий сервис в цепочке упал, а первые два уже зафиксировали изменения. Нужно упомянуть, что компенсация — это не «откат» (rollback) в понимании БД, а новая «отменяющая» операция в бизнес-логике.
В 2026 году стандарт OAuth 2.1 объединил лучшие практики. На интервью могут спросить про отказ от Implicit Flow в пользу PKCE (Proof Key for Code Exchange) даже для серверных приложений. Также актуальна тема Rate Limiting: не просто ограничение по IP, а использование алгоритмов Token Bucket или Leaky Bucket с привязкой к Tier пользователя или конкретному API-ключу.
REST традиционно ассоциируется с JSON, но для внутренних коммуникаций в 2026 году чаще обсуждают gRPC или Avro. Если на интервью просят сравнить их, делайте упор на стоимость сериализации. JSON — текстовый формат, его парсинг нагружает CPU. Бинарные форматы экономят до 30-50% ресурсов процессора и до 40% сетевого трафика за счет отсутствия повторяющихся ключей в каждом сообщении.
PUT по спецификации RFC должен быть идемпотентным: он полностью заменяет ресурс. Повторный вызов с теми же данными даст тот же результат. PATCH не всегда идемпотентен. Если PATCH используется для инкремента значения (например, { "op": "add", "path": "/score", "value": 1 }), то каждый повторный запрос будет увеличивать счетчик, что нарушает идемпотентность.
Есть три способа: 1. PATCH с JSON Merge Patch (простая замена полей). 2. PATCH с JSON Patch (описание операций add, remove, replace). 3. Использование PUT, где клиент присылает объект целиком. В 2026 году для сложных доменных моделей чаще выбирают JSON Patch, чтобы избежать затирания данных при конкурентном доступе.
Это модель оценки зрелости REST API. Уровень 0: HTTP как транспорт для RPC. Уровень 1: Появление ресурсов. Уровень 2: Использование HTTP-глаголов (GET, POST и т.д.). Уровень 3: HATEOAS (Hypermedia as the Engine of Application State), когда API возвращает ссылки на возможные действия с ресурсом.
В REST это решается через: 1. Внедрение параметра `_embed` или `include` для подгрузки связанных сущностей в одном запросе. 2. Создание специализированных ресурсов (View Models). 3. Переход на GraphQL для запросов со сложной вложенностью. На бэкенде важно использовать паттерн DataLoader для батчинга запросов к БД.
Заголовок Vary сообщает кэширующим прокси-серверам, какие заголовки запроса нужно учитывать при поиске закэшированного ответа. Например, `Vary: Accept-Encoding` гарантирует, что клиент, поддерживающий gzip, не получит неавторизованный ответ в открытом виде, который был закэширован для другого клиента.
