Співбесіда з дизайну систем: рамка, яку можна повторити
Раунд із дизайну систем виглядає як перевірка ерудиції, а насправді перевіряє інше: чи вмієте ви рухатися від розпливчастої вимоги до конкретного рішення, не загубившись і не збрехавши собі. Порядок кроків важить більше за знання конкретних технологій.
Крок 1. Вимоги, і не поспішайте
Найдорожча помилка робиться в перші дві хвилини — коли людина чує «спроєктуйте Twitter» і починає малювати сервіси. Спершу з'ясуйте, що саме будуємо.
Функціональні вимоги: що користувач може робити. Нефункціональні: скільки користувачів, яка затримка прийнятна, що важливіше — консистентність чи доступність. П'ять хвилин тут заощаджують двадцять потім.
Крок 2. Оцінка навантаження
Порахуйте вголос: скільки запитів на секунду, скільки даних на день, скільки за рік. Цифри не мусять бути точними — мусять бути озвученими припущення.
«Припустимо, 100 мільйонів активних користувачів на день, кожен робить 10 запитів — це приблизно 12 тисяч запитів на секунду в середньому й до 40 тисяч у пік». Тепер у розмови є масштаб, і подальші рішення можна обґрунтувати, а не вгадувати.
Крок 3. Високорівнева схема
Клієнт, балансувальник, сервіси, сховище, кеш, черга. Малюйте великими мазками й називайте відповідальність кожного блоку. Деталі — потім, за запитом інтерв'юера.
Тут корисно одразу позначити, де дані пишуться, а де читаються: більшість систем мають перекіс у бік читання, і саме він визначає, де знадобиться кеш і реплікація.
Крок 4. Модель даних
Які сутності, які зв'язки, який ключ шардування. Це місце, де реляційна база проти нереляційної перестає бути питанням смаку: якщо потрібні транзакції між сутностями — реляційна, якщо потрібен горизонтальний ріст за простим ключем — інша відповідь.
Вибір ключа шардування варто проговорити окремо. Невдалий ключ створює гарячі партиції, і це те, про що вас майже напевно спитають.
Крок 5. Компроміси, а не рішення
Це найважливіша частина, і саме її пропускають. Кожен вибір має ціну: кеш дає швидкість і породжує неконсистентність; черга згладжує піки й додає затримку; реплікація підвищує доступність і ускладнює запис.
Формулювання, яке працює: «Я обираю X, бо для цієї системи важливіше A. Ціна — B, і я готовий її платити, бо C». Інтерв'юер не шукає ідеального рішення, він шукає усвідомлений вибір.
Крок 6. Вузькі місця й що буде далі
Наприкінці самі назвіть, що зламається першим при зростанні вдесятеро, і як ви це помітите. Метрики, алерти, деградація під навантаженням.
Кандидат, який сам знаходить слабке місце у власному дизайні, справляє сильніше враження за того, кого до цього довели уточненнями.
Типові причини провалу
Мовчазне малювання: інтерв'юер не бачить ходу думок і не може допомогти. Називання технологій замість пояснення механізму — «візьмемо Kafka» без відповіді на «чому черга взагалі». І дизайн без чисел: без оцінки навантаження будь-яке рішення однаково правильне й однаково беззмістовне.
Приклад: як рамка виглядає на живій задачі
Візьмімо «спроєктуйте стрічку новин». За рамкою вище перші п'ять хвилин виглядають так.
Вимоги: користувач бачить пости тих, на кого підписаний, у зворотному хронологічному порядку; може публікувати; стрічка має вантажитися швидко. Нефункціональні: 50 мільйонів активних на день, затримка до 200 мс, доступність важливіша за миттєву консистентність — якщо пост з'явиться в чужій стрічці із запізненням на секунду, ніхто не постраждає.
Оцінка: 50 мільйонів × 20 переглядів стрічки = мільярд читань на день, приблизно 12 тисяч на секунду. Записів на два порядки менше. Це вирішальна цифра: система на читання, отже кеш і денормалізація виправдані.
Далі — ключове архітектурне рішення: збирати стрічку під час читання чи розкладати пости по підписниках під час запису. Обидва варіанти правильні, і саме порівняння їх, а не вибір «кращого», є відповіддю на питання.
Fan-out: класичний компроміс, який варто вміти проговорити
Розкладати під час запису означає: коли людина публікує пост, ми одразу кладемо його в готові стрічки всіх підписників. Читання стає майже безкоштовним, запис — дорогим.
Збирати під час читання означає протилежне: пост зберігається один раз, а стрічка формується запитом у момент відкриття. Запис дешевий, читання дороге.
Правильна відповідь — гібрид, і причина конкретна: у користувача з десятьма мільйонами підписників розкладання під час запису породжує десять мільйонів операцій на один пост. Тому для звичайних авторів працює fan-out на запис, а для великих акаунтів їхні пости домішуються під час читання. Цей приклад варто вміти розповісти, бо він показує саме те, що перевіряють: розуміння, що вибір залежить від розподілу навантаження, а не від моди.
Про що спитають майже напевно
Кеш: де стоїть, що інвалідує, що буде при холодному старті. Відповідь «поставимо Redis» без пояснення стратегії інвалідації читається як завчена.
Консистентність: що бачить користувач одразу після власної дії. Класична пастка — система з реплікацією для читання, де людина публікує пост і не бачить його у власній стрічці. Рішення (читати власні записи з майстра) просте, але його треба назвати самому.
Ідемпотентність: що буде, якщо клієнт повторить запит через таймаут. Для будь-якої операції, що змінює стан, потрібен ключ ідемпотентності — і це те, про що забувають навіть сильні кандидати.
Обмеження частоти: як захищаємося від зловживань. Достатньо назвати підхід (token bucket) і місце, де він стоїть.
Як говорити, коли не знаєте
У раунді з дизайну систем нормально не знати конкретну технологію. Ненормально — вдавати, що знаєте. Інтерв'юери майже завжди чують блеф і майже завжди цінують чесність.
Робоче формулювання: «З цим конкретним інструментом я не працював, але задача тут — розподілена черга з гарантією доставки. Я б розв'язував так, і ось на які властивості дивився б, обираючи інструмент». Ви показуєте, що розумієте суть, і не претендуєте на досвід, якого немає.
Це саме те місце, де сеньйор відрізняється від міда: не обсягом вивчених назв, а здатністю звести незнайоме до знайомої властивості.
Розподіл часу в межах раунду
На сорок п'ять хвилин розумний розподіл такий: п'ять на вимоги, п'ять на оцінку, десять на високорівневу схему, десять на модель даних і деталі, десять на компроміси й вузькі місця, п'ять на запитання інтерв'юеру.
Найчастіше збиваються на третьому кроці — заглиблюються в деталі одного компонента й не встигають дійти до компромісів, тобто до найважливішої частини. Якщо відчуваєте, що загрузли, скажіть це вголос: «зафіксуємо тут таке рішення й повернемось, якщо буде час» — це сприймається як контроль над розмовою, а не як ухиляння.