Досье по проектированию системы

Большинство провальных проектов проваливаются именно здесь: кандидат начинает рисовать прямоугольники, ещё не решив, что система вообще должна своим пользователям. Выбери свою систему и запиши, что входит в объём работ и — что не менее важно — что явно остаётся за его пределами. Раздели функциональные требования («создать короткую ссылку», «развернуть короткую ссылку в её цель», «истечение срока ссылок») и нефункциональные, которые определяют всю форму проекта: целевой QPS, соотношение чтений к записям, бюджет задержки p99 для редиректа, долговечность и насколько устаревшим разрешено быть результату. Для сократителя URL ключевой факт в том, что чтений на порядки больше, чем записей, — назови это соотношение явно, ведь на него опирается каждое последующее решение. Не отделывайся фразами «должно быть быстро и масштабируемо»: преврати каждое прилагательное в число, за которое ты отвечаешь.

Теперь преврати требования в числа, которые ограничивают архитектуру. Оцени записи в день и чтения в день из заявленного соотношения, переведи в средний и пиковый QPS, а затем выведи то, что определяет стоимость: сколько байт занимает одна запись, сколько записей накопится за пять лет, суммарный объём хранения и рабочий набор кэша, который поглотил бы горячий хвост чтений. Для самого короткого кода посчитай размер пространства ключей — сколько символов base-62 нужно, чтобы не закончились уникальные ссылки, — потому что именно этот расчёт диктует стратегию генерации ID. Запиши каждое допущение (средний URL — около 100 байт, год — примерно 31,5 млн секунд), чтобы ревьюер мог оспорить входные данные, а не только результат. Цель — не точный прогноз, а модель порядка величины, которая подсказывает, один сервер или тысяча серверов — правильная стартовая картина.

Модель нагрузки уже подсказала форму работы: крошечная запись, подавляющий паттерн чтения по ключу и почти полное отсутствие реляционных соединений. Пусть это и определяет модель данных, а не привычка. Опиши запись (короткий код, длинный URL, владелец, время создания, опциональный срок истечения) и реши, каким будет первичный ключ, а затем обоснуй выбор хранилища по существу: key-value-хранилище или одна индексированная таблица читают по первичному ключу почти за O(1) и чисто шардируются по коду, тогда как богатая реляционная схема покупает тебе соединения, которые ты никогда не выполнишь. Спроектируй API под это: путь записи, который чеканит код, и путь чтения, который представляет собой одиночный поиск, возвращающий редирект. Отнесись осознанно к самому редиректу: 301 кэшируется навсегда и дёшев, но лишает тебя подсчёта кликов, а 302 заставляет каждый переход возвращаться к тебе; этот выбор — настоящий продуктовый компромисс, а не деталь. Опиши форматы запроса и ответа и статус-коды для несчастливых путей (неизвестный код, истёкшая ссылка).

Проект под нагрузкой хорош ровно настолько, насколько понятно, где он падает. Проследи путь редиректа по своей высокоуровневой диаграмме и найди компонент, который насыщается первым при вычисленном тобой пиковом QPS, — для сократителя это почти всегда путь чтения, долбящий хранилище, или конкуренция за то, что чеканит новые коды. Назови его точно, а затем точно устрани. Стандартное решение для чтения — кэш перед хранилищем, рассчитанный на твой рабочий набор, но кэш вынуждает принимать реальные решения: какая политика вытеснения, какой TTL и что происходит при промахе или холодном старте — лавина запросов (cache stampede) на популярном коде может оказаться хуже, чем кэш вовсе. Если узкое место — генерация ID, сопоставь стратегии: счётчик, раздаваемый диапазонами, хэш с обработкой коллизий или предгенерированные ключи из пула, — и выбери одну, помня про её поведение при отказе. Закончи новым узким местом, которое обнажает твоё исправление, ведь устранение одного всегда вскрывает следующее.

Сеньорскую работу оценивают по несчастливому пути. Напиши раздел про режимы отказа: что происходит, когда падает узел кэша, когда реплика основного хранилища отстаёт, когда гаснет зона доступности и когда трафик на одну вирусную ссылку концентрируется на одном шарде (проблема горячего ключа). Для каждого случая назови радиус поражения и плавную деградацию: редирект переживёт устаревший кэш, но чеканка совершенно нового кода, возможно, должна отказывать «закрыто», лишь бы не рискнуть дубликатом. Затем честно напиши раздел про масштабирование: объясни, как путь чтения масштабируется горизонтально за балансировщиком и CDN, как ты шардируешь пространство ключей по коду, чтобы рост сводился к добавлению шардов, и где проект упирается в стену, которую большая машина не пробьёт. Свяжи это с требованиями из первого этапа: цель доступности 99,99% — это бюджет примерно в 52 минуты простоя в год, и каждый перечисленный режим отказа тратит из него.

Каждое решение в досье закрыло какую-то альтернативу, и проект, делающий вид, что это не так, выглядит наивным. Собери реестр компромиссов: для каждого крупного выбора — key-value против реляционного хранилища, 301 против 302, ID на счётчике против ID на хэше, строгая против итоговой согласованности для только что созданной ссылки — укажи, что ты выбрал, чем пожертвовал и при каком условии выбрал бы иначе. Именно здесь кусается согласованность: пользователь, который создал ссылку и сразу ею поделился, ждёт, что она развернётся, поэтому «итогово согласованные чтения» — это обещание, которое нужно оговорить. Заверши досье коротким абзацем «если бы требования изменились»: что перевернётся, если записи вдруг сравняются с чтениями или если продукт потребует аналитику по кликам, — доказывая, что проект это обоснованная позиция, а не заученный шаблон. Ревьюер должен иметь возможность не согласиться с выбором и всё же увидеть, что ты понимал его цену.