По уровням: дисциплина совместимых изменений → схема как источник истины → автоматическая проверка совместимости в CI → контрактные тесты от потребителей.
А ещё Неизбежные изменения — expand–contract, метрики использования старой версии и политика поддержки
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
1. Дисциплина изменений. По умолчанию — только добавления; клиенты — толерантные читатели.
2. Схема — источник истины. OpenAPI для REST, protobuf для gRPC, Avro/JSON Schema для событий. Клиенты генерируются из схемы, а не пишутся по документации, которая отстаёт от кода.
3. Автоматическая проверка совместимости. В CI сравнивается новая схема со старой (openapi-diff, buf breaking для protobuf); для событий — Schema Registry с режимом совместимости BACKWARD или FORWARD: реестр не даст зарегистрировать ломающую версию.
4. Контрактные тесты, управляемые потребителем. Каждый потребитель описывает запросы, которые он делает, и поля, которые читает (Pact). Провайдер в своей сборке проверяет, что удовлетворяет всем опубликованным контрактам, — и узнаёт о поломке до выкатки. Это позволяет отказаться от хрупких сквозных тестов всей системы и общего релизного поезда.
5. Когда ломать необходимо: expand–contract (новое рядом со старым), метрики, кто ещё зовёт старую версию (по заголовку клиента или ключу API), объявленный срок поддержки и уведомление потребителей.
Выбор стиля взаимодействия, семантика и идемпотентность HTTP, формат ошибок, курсорная пагинация против offset, версионирование и обратная совместимость, контрактное тестирование.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto