Фундаментальные кейсы: напишите полный дизайн-документ
Практический проект: возьми один из четырёх фундаментальных кейсов и сделай полный дизайн-документ — требования, оценка на салфетке, диаграмма высокоуровневой архитектуры, два глубоких погружения и раздел узких мест и компромиссов.
Прочитать четыре разобранных кейса — не то же, что сделать один самому под ограничениями, которые навязывает реальное ревью. Выбери одну из четырёх систем, напиши полный дизайн-документ от начала до конца — требования, оценку, выбирающую форму, архитектуру, два сложных компонента и режимы отказа — и защити каждый порог числом, которое staff-инженер сможет проверить.
Этот проект делает юнит операционным: ты прогоняешь полный цикл дизайна для одной системы, обосновываешь каждое решение арифметикой из кейсов и вскрываешь компромиссы, отделяющие дизайн, что работает, от того, что выживает. Результат — документ, не код; навык — рассуждение, не печатание.
Сделай полный senior-уровня дизайн-документ для ОДНОЙ из четырёх фундаментальных систем (распределённое key-value хранилище, сокращатель URL, веб-краулер или распределённая очередь сообщений), следуя той же структуре, что использовали кейсы: требования → оценка → высокоуровневый дизайн → глубокое погружение → узкие места и компромиссы. Каждый числовой порог в документе обоснован оценкой на салфетке, а каждый выбор компонента — явным компромиссом.
- Дизайн-документ со всеми пятью разделами (требования, оценка, HLD с диаграммой, два глубоких погружения, узкие места), читаемый примерно за десять минут другим инженером.
- Каждый числовой порог подкреплён показанным расчётом (без голых чисел), и документ явно называет, какой ресурс ломается первым.
- Каждый из двух компонентов глубокого погружения называет механизм И отвергнутую альтернативу, с причиной — а не просто описание выбранного дизайна.
- Раздел узких мест называет хотя бы четыре реальных режима отказа, специфичных для выбранной системы, каждый с митигацией, а не общие ответы «добавить серверов».
- Ревьюер может не согласиться с выбором и увидеть ровно, какое допущение поменять — каждое решение прослеживается до заявленного требования или числа.
- Напиши документ для ВТОРОЙ системы и извлеки общий скелет: какие ходы (партиционировать, реплицировать, дедупить, кешировать, упорядочить) повторяются и что меняет форму между двумя.
- Добавь раздел роста 10x: пересчитай оценку при 10x нагрузке и определи первый порог, что пересекаешь (новый шард, слой кеша, больше партиций) и что в дизайне должно поменяться.
- Добавь явную позицию согласованность/доступность: скажи, где твоя система сидит на CAP/PACELC, и проведи ровно, что сетевое разделение делает с чтениями и записями.
- Раскритикуй один из четырёх разобранных кейсов: найди требование, что он недообслужил, или компромисс, что он замял, и предложи изменение с числом, что его обосновывает.
- 01Каковы пять разделов дизайн-документа и что даёт каждый?
- 02Почему обосновывать каждый порог числом и называть отвергнутую альтернативу?
- 03Что делает «диктующее требование» и почему найти его первым?
Этот проект превращает четыре кейса в повторяемый рабочий процесс, применимый к любому запросу «спроектируй X». Выбери одну систему и напиши пятиразделный дизайн-документ: требования (и единственное нефункциональное, что диктует остальное — всегда-доступно-для-записи, read-heavy, никогда-не-перегружать-хост или надёжный-шланг); оценку, что выводит QPS, хранение и цифру памяти/пропускной способности до одной значащей цифры и называет, какой ресурс ломается первым; высокоуровневый дизайн с диаграммой и проводкой запроса; два глубоких погружения, каждое с механизмом и отвергнутой альтернативой с причиной; и раздел узких мест и компромиссов, называющий хотя бы четыре реальных режима отказа с митигациями. Обоснуй каждый порог показанным расчётом, чтобы ревьюер мог не согласиться, поменяв допущение, и зафиксируй компромисс за каждым выбором. Инженер, написавший один такой от начала до конца, перестаёт обращаться с системным дизайном как с заученной диаграммой и начинает обращаться с ним как с рассуждением с числами — ровно тем, чему учит весь трек.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.