Архитектурная защита: четыре системы и изменение требований

Вам предлагают спроектировать «ещё один чат». Можно быстро нарисовать сервер, очередь и базу. Но без требований невозможно понять, какую историю сообщения эта схема обязана сохранять: доставку онлайн, восстановление пропуска, порядок внутри диалога или отзыв доступа. В этом блоке название продукта — только начало разговора.

Четыре задания используют собственные учебные условия. Они развивают навыки переноса решения на незнакомую задачу. Все числа — входные данные упражнения, а не статистика известных компаний. Выполните хотя бы одно задание полностью, затем защитите второе без готового ответа. Темы сквозного интервью-разбора представлены в программах Educative и Alex Xu; здесь проверяется самостоятельный протокол.

Как выглядит достаточное решение

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

В архитектурной записи нужны: обязательства пользователю; место принятия решения; состояние до и после commit; результат повторного запроса; время жизни данных; эксплуатационный показатель; альтернативный вариант; способ проверки. На схеме каждая стрелка обозначает сообщение или поток данных. Прямоугольник «надёжный сервис» без протокола не считается объяснением.

Кейс 1. Уведомления, которые нельзя отправить повторно молча

«Клуб» обслуживает 100 000 участников. До 5000 уведомлений/минуту, пиковая кампания содержит 200 000 сообщений. Нужны email и push, пользователь выбирает каналы и может отозвать согласие. Приоритет имеют напоминания о событиях в ближайшие десять минут. Провайдер одного канала иногда отвечает с задержкой 20 секунд. Его мощность — 300 сообщений/с, дубликаты возможны.

Артефакты: состояния доставки по каналу, дедупликационный ключ, очереди приоритетов, политика ретраев, таблица отказов и сверка результатов. Определите, означает ли accepted отправку провайдеру, принятие провайдером или подтверждение устройства. Уведомление на двух каналах — две связанные доставки, а не обязательно один внешний эффект.

Разобранная нижняя оценка: 200 000 / 300 ≈ 667 секунд, больше 11 минут, без прочей нагрузки и повторов. Сохранить требование для срочных сообщений одной общей FIFO-очередью может не получиться. Нужны резерв мощности, приоритет с защитой от голодания или изменение сроков кампании. При повторе таймаута нельзя считать, что провайдер точно ничего не отправил.

Изменение: согласие отозвано после помещения сообщения в очередь. Назовите последний момент проверки права на отправку и договор уже начатого внешнего действия. Удаление элемента из интерфейса не отменяет письмо, которое уже принял провайдер.

Кейс 2. Найти ближайшие учебные площадки

Есть 500 000 площадок, запрос задаёт координаты и радиус до 10 км. Пиковая нагрузка 2000 запросов/с. Координаты площадки меняются редко, доступность зала — каждую минуту. Требуется ограниченный top-20 список с пояснением свежести доступности. Это поиск площадок, а не диспетчеризация транспорта в реальном времени.

Разделите геометрических кандидатов и актуальную доступность. Геоячейка даёт дешёвый грубый поиск, но её граница не совпадает с кругом запроса. Выбираем соседние ячейки, затем проверяем точное расстояние выбранной моделью. Один hash координат не означает, что ближайшие точки всегда имеют ближайшие номера. Для большой территории и точности задайте систему координат и геодезическую функцию; плоская учебная модель не покрывает весь земной шар.

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

Изменение: необходимо гарантировать отсутствие двух броней одного зала. Этот инвариант защищает операция бронирования, а не геопоиск. Добавьте путь актуальной проверки и покажите, почему выдача «свободно» может всё ещё завершиться отказом при записи.

Кейс 3. Синхронизация учебных файлов

У пользователя до трёх устройств, размер файла до 200 MB, сеть периодически пропадает. Одновременно могут редактироваться два разных файла и один и тот же файл. Исходное требование: не терять подтверждённые версии; автоматически объединять произвольные бинарные файлы не требуется.

Храним версионированные метаданные отдельно от immutable-объектов. Клиент начинает multipart/resumable загрузку, проверяет завершение и только затем публикует версию метаданных. Оборванная загрузка оставляет временный объект, который убирается по отдельному протоколу. Продолжение загрузки должно связываться с нужным пользователем, объектом и допустимыми частями.

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

При 10 000 полных загрузках по 200 MB получаем 2 TB входящих данных без повторов и служебных расходов. Delta-обновления могут сократить трафик, но требуют протокола базовой версии и проверки восстановленного объекта. Нельзя заявлять фиксированную экономию без распределения изменений.

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

Кейс 4. Запуск в десять раз выше обычного пика

Через месяц открывается запись на популярное событие: 50 000 пользователей приходят в первые 30 секунд, каждый делает в среднем четыре API-запроса. На записи нельзя превышать вместимость. Каталог может отставать до минуты. Есть основной и резервный регион, но подтверждённые записи не разрешено терять при автоматическом переключении.

Средний вход за окно старта: 200 000 / 30 ≈ 6667 запросов/с. Реальный секундный максимум пока неизвестен. Разделите чтения каталога, авторизацию, попытки бронирования и повторы. Даже если 95% чтений попадает в CDN, это не доказывает достаточность мощности пути записи.

План включает нагрузочный профиль, admission control, защиту ресурса, бюджет зависимостей, клиентские ретраи с jitter, наблюдение за успешной записью и процедуру остановки. Резервный регион может продолжить чтения из допустимо устаревших данных; запись с нулевым RPO требует подтверждённого протокола и запрета конкурирующих писателей. Если необходимое большинство недоступно, прежнее обещание может требовать отказа от записи.

Изменение: резервный регион восстановлен из вчерашней копии. Он не становится актуальным только потому, что health check зелёный. Опишите догон журнала, сверку, fencing старого писателя и критерий возврата. Подробнее — разбор нескольких регионов.

Рубрика защиты

Оцените пять областей от 0 до 3: требования, модель и инварианты, протокол отказов, численные бюджеты, проверка и эксплуатация. Ноль означает противоречие условию; один — названные компоненты; два — объяснённый нормальный путь и один отказ; три — сохранение заявленных инвариантов при изменении условия с наблюдаемой проверкой.

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

Выходной пакет: короткое ТЗ, схема, расчёт с единицами, две временные трассы, ADR о главном выборе, инструкция эксперимента и вывод по новому условию. На интервью вы обсуждаете сокращённую версию; для эксплуатации дополнительно нужны измерения на целевой среде, runbook, восстановление, ответственность за инциденты и безопасное изменение. Связь SLO с эксплуатационными решениями разбирается в Google SRE Workbook.