Защита: объяснить решение и выдержать новое требование

Покажите систему целиком

Ваш проект принимает запросы, ограничивает работу, сохраняет записи и восстанавливается после перезапуска. Защита проверяет, можете ли вы объяснить решения и их границы. Человек, который не видел ваш код, должен по README запустить сервис, повторить один опыт и понять, что произойдёт при ошибке.

Эталон проекта доступен бесплатно. Открывайте его после своей попытки, распаковывайте в другую папку и сравнивайте конкретный вопрос: защита состояния, порядок сохранения или отмена ожидания. Скопированный эталон с зелёными тестами не проверяет самостоятельность. После сравнения закройте его и объясните решение своими словами.

Что прочитать

Прочитайте архитектурную защиту и разделы об изменении требований в собеседовании и практике. Если сравниваете будущие варианты хранения или несколько процессов, вернитесь к данным, очередям и событиям, изменениям системы. Их продвинутые разделы — продолжение обучения, а не скрытый входной экзамен этого проекта.

Подготовьте пакет доказательств

В README укажите команды запуска, конфигурацию, методы и ответы API. Нарисуйте путь POST → запись → очередь → Process → сохранение → GET; рядом отметьте владельцев состояния и точки ожидания. Опишите переходы queued, running, done, failed, временную ошибку и восстановление.

Запишите границы: один процесс, локальный файл, ограниченная очередь, кооперативная отмена, возможная повторная обработка. Объясните разницу между сохранённым заданием и внешним эффектом. Вложите отчёт прошлого этапа и команды тестов:

go test ./... -count=1
go test -race ./... -count=1
go build ./...

Общие тесты включают всё реализованное ядро. Они не оценивают вашу речь, рисунок, полноту README и новое требование ниже. Для этих частей нужны ваши сценарии и осмысленный просмотр другим человеком либо самостоятельная проверка по критериям.

Изменение требования: два клиента

Сервисом начали пользоваться два клиента — A и B. A постоянно отправляет много заданий. B отправляет одно короткое задание время от времени и не должен бесконечно ждать из-за потока A. Теперь вход содержит идентификатор клиента. Уже принятые задания должны сохраняться и восстанавливаться, а общий предел одновременно выполняемой работы должен остаться ограниченным.

Готового решения этой части в архиве нет. До изменения кода сформулируйте договор:

• Что значит «B не ждёт бесконечно»: какой проверяемый предел или правило обслуживания вы обещаете при конечной длительности каждой работы?
• Как ограничивается приём, когда один клиент занял допустимое ожидание? Какие ответы получат A и B?
• В какой области действует Idempotency-Key: для всего сервиса или внутри одного клиента? Как это отражается в сохранении?
• Что происходит с правилом обслуживания после перезапуска и во время остановки?

Не обещайте конечное время ответа, если одна Process может никогда не вернуть управление. Явно задайте условия обещания. Здесь идентификатор клиента — учебное поле, а не доказательство его личности; настоящая аутентификация потребовала бы отдельного договора безопасности.

Докажите своё решение

Сначала напишите тест: A удерживает постоянный входной поток, B добавляет задание, все работы имеют управляемую конечную длительность. Покажите, при каких условиях B обслуживается по вашему правилу. Затем проверьте заполнение ожидания, одинаковые ключи двух клиентов, восстановление и остановку. Прогоните старые тесты: изменение требований не разрешает сломать сохранение, лимит обработчиков и статусы.

Предложите два возможных подхода в записке, выберите один и объясните, какой недостаток готовы принять. Докажите выбранное свойство своим тестом и измерением; название алгоритма само по себе не доказательство. Можно отказаться от части старого поведения, если это необходимо, но изменение договора должно быть явным и проверяемым.

Частые ошибки: обещать справедливость без определения; проверять B только при пустой системе; решать проблему увеличением буфера; считать id клиента авторизацией; добавлять новые горутины без общего предела.

Путь завершён, когда есть результат

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

Это законченный учебный результат, а не гарантия готовности к любой работе. Дальнейшую практику выбирайте по наблюдаемому пробелу: транзакционное хранилище, несколько экземпляров сервиса, безопасность API или измерения на другом оборудовании. Не требуется пройти весь каталог, чтобы закончить этот путь.