System Design: як підготуватися до співбесіди

System Design — це вміння спроєктувати програмну систему так, щоб вона розв’язувала бізнес-завдання, витримувала навантаження, відновлювалася після збоїв і залишалася зрозумілою для команди. На співбесіді з System Design від тебе чекають не «єдино правильної» схеми, а здатності ставити уточнювальні запитання, пояснювати компроміси й думати вголос.

Таку співбесіду зазвичай дають middle+, senior і staff-розробникам, але готуватися варто раніше. Вона перевіряє, чи бачиш ти систему ширше за одну функцію: API, базу даних, кеш, черги, індекси, масштабування, моніторинг, безпеку та вартість підтримки.

Найважливіше: System Design — це не набір модних слів. Це практичний спосіб відповісти на запитання: що станеться, коли користувачів стане у 10 разів більше, база сповільниться, сервер упаде, а команда захоче додати нову функцію без переписування всього з нуля.

Що таке System Design

System Design, або проєктування систем, — це процес визначення архітектури програмного продукту: які компоненти потрібні, як вони взаємодіють, де зберігаються дані, як система обробляє запити, масштабується й відновлюється після збоїв.

У маленькому застосунку багато що може жити в одному процесі: UI, бізнес-логіка, доступ до бази даних, фонові задачі. Але коли з’являються тисячі користувачів, аналітика, платежі, сповіщення, пошук, файли й інтеграції з іншими сервісами, систему доводиться проєктувати свідомо.

System Design відповідає на такі запитання:

1. Які вимоги має система: функціональні й нефункціональні?
2. Які основні об’єкти та потоки даних?
3. Яке API потрібне клієнтам або іншим сервісам?
4. Де та як зберігати дані?
5. Як система витримає навантаження?
6. Що станеться під час збою?
7. Які компроміси ми приймаємо?

Метафора System Design як міської мережі з потоками, вузлами й резервами

Як виглядає співбесіда з System Design

Зазвичай інтерв’юер дає відкриту задачу: спроєктуй скорочувач посилань, чат, стрічку новин, сервіс доставки, систему бронювання квитків або файлове сховище. У тебе є 40–60 хвилин, дошка або спільний документ і потреба пояснювати думки вголос.

Типовий перебіг такий:

1. Ти уточнюєш вимоги.
2. Оцінюєш масштаб: користувачі, запити, обсяг даних.
3. Пропонуєш високорівневу архітектуру.
4. Проєктуєш API та модель даних.
5. Обговорюєш вузькі місця.
6. Додаєш кешування, черги, реплікацію, шардінг або інші механізми, якщо вони потрібні.
7. Пояснюєш компроміси й ризики.

На такій співбесіді рідко оцінюють, чи знаєш ти назву конкретного сервісу в AWS або Google Cloud. Набагато важливіше, чи можеш пояснити, чому обрав кеш, що буде з неузгодженими даними, як система поводиться під навантаженням і що ти зробиш у разі збою.

Базові поняття, без яких важко

Функціональні та нефункціональні вимоги

Функціональні вимоги описують, що система має робити. Нефункціональні — якою вона має бути: швидкою, надійною, безпечною, масштабованою, зручною в підтримці.

Приклади:

• У сервісі бронювання важливо не лише показати вільні місця, а й не продати одне місце двом людям.
• У стрічці новин можна прийняти невелику затримку оновлення, але не можна віддавати сторінку 10 секунд.
• У банківській системі узгодженість важливіша за швидкість, а в лічильнику переглядів часто навпаки.

Latency, throughput і availability

Latency — затримка, тобто скільки часу минає від запиту до відповіді. Throughput — пропускна здатність: скільки запитів або подій система обробляє за секунду. Availability — доступність: частка часу, коли система працює для користувачів.

Ці поняття часто конфліктують. Можна зробити дуже надійну систему, але вона буде дорожчою. Можна зробити швидку відповідь через кеш, але доведеться миритися з тим, що дані інколи будуть не найсвіжіші.

Узгодженість даних

Consistency — узгодженість даних. Strong consistency, або сильна узгодженість, означає: після запису всі читання бачать найновіший стан. Eventual consistency, або кінцева узгодженість, означає: система може короткий час показувати застарілі дані, але згодом усі копії синхронізуються.

CAP theorem, або теорема CAP, корисна як ментальна модель: у розподіленій системі під час мережевого розділення доводиться обирати між строгішою узгодженістю та доступністю. На співбесіді важливо не цитувати CAP механічно, а пояснювати, який компроміс ти приймаєш у конкретній задачі.

Масштабування: вертикальне й горизонтальне

Вертикальне масштабування — дати одному серверу більше CPU, пам’яті або диска. Горизонтальне — додати більше серверів.

На співбесіді не варто автоматично казати: «Додамо Kubernetes — і все». Спершу поясни, що саме не витримує навантаження: API, база, пошук, черга, кеш чи зовнішня інтеграція.

Кеш, черги, реплікація, шардінг

Кеш — швидке тимчасове сховище для даних, які часто читають. Наприклад, Redis може зберігати профілі користувачів або результати популярних запитів.

Черга повідомлень — механізм для асинхронної обробки. Коли користувач завантажує відео, система може швидко відповісти: «Файл прийнято», а кодування відео виконати у фоні.

Реплікація — копіювання даних між кількома базами або вузлами. Вона допомагає читати з копій і переживати збій основного вузла.

Шардінг — поділ даних на частини. Наприклад, користувачі з id 1–1 000 000 зберігаються в одному шарді, наступні — в іншому. Це складніше за реплікацію, бо з’являються питання розподілу, запитів між шардами, міграцій і балансування даних.

Алгоритм відповіді на співбесіді

Добра відповідь на співбесіді з System Design має структуру. Вона допомагає не загубитися й показує інтерв’юеру, що ти мислиш системно.

1. Уточни задачу

Почни з меж системи. Якщо просять спроєктувати чат, запитай:

• Це чат один на один чи групові розмови?
• Потрібна історія повідомлень?
• Чи мають бути push-сповіщення?
• Чи потрібні вкладення: фото, відео, файли?
• Скільки користувачів і активних з’єднань очікуємо?

Це не формальність. Архітектура чату для 10 тисяч користувачів і для 100 мільйонів буде різною.

2. Визнач вимоги та обмеження

Запиши 3–5 функціональних вимог і 3–5 нефункціональних. Не намагайся охопити все.

Наприклад, для скорочувача посилань.

Функціональні вимоги:

1. Створити коротке посилання для довгого URL.
2. Перенаправити користувача за коротким кодом.
3. Показати базову аналітику переходів.

Нефункціональні вимоги:

1. Дуже швидке перенаправлення.
2. Висока доступність.
3. Значно більше читань, ніж записів.
4. Захист від зловживань: спаму, надмірних запитів, шкідливих URL.

Останні пункти одразу підказують: кеш буде корисним, база має добре витримувати читання, а на API потрібні rate limiting і перевірки безпеки.

3. Зроби грубу оцінку масштабу

Оцінки не мають бути ідеальними. Вони потрібні, щоб зрозуміти порядок величин.

Приклад: 10 млн активних користувачів на день, кожен робить 20 читань стрічки.

• 200 млн читань на день.
• 200 млн / 86 400 ≈ 2 315 читань на секунду в середньому.
• У піку може бути в 5–10 разів більше: приблизно 12–23 тисячі читань на секунду.

Такі числа змінюють дизайн. Те, що працює для 100 запитів на секунду, може не працювати для 20 тисяч.

4. Намалюй високорівневу архітектуру

Почни просто:

Клієнт → балансувальник навантаження → API-сервіси → база даних.

Потім додавай компоненти за потреби:

• кеш для «гарячих» читань;
• чергу для фонових задач;
• сховище об’єктів для файлів;
• пошуковий індекс для повнотекстового пошуку;
• репліки бази для читання;
• CDN для статичних файлів;
• rate limiter для обмеження надмірних запитів.

5. Поясни компроміси

Компроміс — серце System Design. Немає безкоштовних рішень.

Якщо ти говориш про модель даних у SQL, варто добре розуміти зв’язки між таблицями. Для повторення можеш подивитися статтю SQL JOIN простими словами.

Приклад: проєктуємо стрічку новин

Розгляньмо задачу, яку часто дають на співбесіді з System Design: спроєктувати стрічку новин для соціальної мережі.

Вимоги

Функціональні вимоги:

1. Користувач може створити пост.
2. Користувач може підписатися на іншого користувача.
3. Користувач бачить стрічку постів від тих, на кого підписаний.
4. Стрічка підтримує пагінацію.

Нефункціональні вимоги:

1. Читання стрічки має бути швидким.
2. Система має витримувати пікові навантаження.
3. Допускається затримка появи нового поста в стрічці на кілька секунд.
4. Пост не має зникати після створення.
5. Повторна обробка подій не має створювати дублікати.

API

Можливі маршрути API:

API не треба деталізувати до кожного поля, але корисно назвати ключові сутності: user, post, follow, feed item.

Модель даних

Мінімальні таблиці або колекції:

Таблиця feed_items не завжди потрібна. Вона з’являється, якщо ми вирішуємо попередньо формувати стрічку для швидкого читання.

Для SQL-моделі варто згадати індекси:

• posts(author_id, created_at) — швидко знайти пости автора;
• follows(followee_id) — знайти підписників автора;
• feed_items(user_id, created_at) — швидко віддати стрічку користувача;
• унікальний ключ feed_items(user_id, post_id) — не створювати дублікати під час повторної обробки події.

Архітектура

Один із варіантів:

1. Користувач створює пост через API.
2. API записує пост у базу даних.
3. Подія про новий пост потрапляє в чергу.
4. Фонові worker-процеси, тобто обробники задач, читають подію.
5. Вони знаходять підписників автора.
6. Для кожного підписника додають feed_item або оновлюють кеш стрічки.
7. Коли користувач відкриває стрічку, API читає готові feed_items із кешу або бази.

Приклад архітектури стрічки новин із кешем, чергою повідомлень і базою даних

Цей підхід називають fan-out on write: розповсюдження під час запису. Він робить читання швидким, але створення поста може бути дорогим, якщо в автора мільйони підписників.

Альтернатива — fan-out on read: формувати стрічку під час читання. Тоді створення поста дешеве, але відкриття стрічки може бути повільним, особливо якщо користувач підписаний на тисячі авторів.

Реальні системи часто використовують гібрид:

• для звичайних авторів — fan-out on write;
• для дуже популярних авторів — додавати їхні пости під час читання;
• кешувати першу сторінку стрічки;
• оновлювати стрічку асинхронно через чергу;
• обмежувати кількість старих feed_items, які зберігаються для кожного користувача.

Вузькі місця

Для стрічки новин варто проговорити:

• «гарячих» користувачів із мільйонами підписників;
• повільне читання через складні JOIN;
• дублювання даних у feed_items;
• очищення старих елементів стрічки;
• порядок постів і пагінацію;
• поведінку під час збою worker-процесів;
• повторну обробку подій із черги;
• моніторинг затримки між створенням поста й появою у стрічці.

Тут важливо не сипати назвами технологій, а пояснити наслідки. Наприклад: якщо worker упаде після запису половини feed_items, подію треба обробити повторно без дублікатів. Для цього допомагають ідемпотентність, тобто безпечне повторення операції, і унікальні ключі.

Як підготуватися до System Design

Підготовку краще будувати не навколо зазубрювання готових схем, а навколо повторюваного процесу.

1. Закрий базові теми

Мінімум, який варто знати:

• HTTP, REST, WebSocket;
• бази даних: індекси, транзакції, реплікація;
• кешування: TTL, invalidation, cache-aside;
• черги повідомлень і фонова обробка;
• балансування навантаження;
• CAP theorem на рівні практичних компромісів;
• consistency: strong, eventual;
• rate limiting;
• observability: логування, метрики, трасування;
• безпека: автентифікація, авторизація, шифрування.

Якщо ти паралельно прокачуєш backend-основи, може знадобитися системне повторення мови та середовища. Для JavaScript-напрямку доречно почати зі статті JavaScript з нуля.

2. Розбирай типові задачі

Почни з простіших:

1. Скорочувач посилань.
2. Сервіс завантаження файлів.
3. Лічильник переглядів.
4. Черга задач.
5. Система сповіщень.

Потім переходь до складніших:

1. Чат.
2. Стрічка новин.
3. Пошук.
4. Система бронювання.
5. Платіжна система.
6. Рекомендаційна система.

Для кожної задачі не просто читай готове рішення. Проговорюй уголос: вимоги, API, дані, архітектура, вузькі місця, компроміси.

3. Тренуй оцінки

Корисно швидко рахувати приблизні навантаження:

• запити на секунду;
• обсяг даних на день і на рік;
• співвідношення читань і записів;
• розмір кешу;
• кількість партицій або шардів.

Приклад: якщо сервіс отримує 50 млн подій на день, це приблизно 579 подій на секунду в середньому: 50 000 000 / 86 400 ≈ 579. Але пікове навантаження може бути 5 тисяч на секунду або більше. Проєктувати треба з урахуванням піків, а не лише середнього значення.

4. Вчися говорити про невизначеність

На реальній співбесіді тобі можуть не дати всі дані. Нормальна фраза: «Припущу, що читань у 20 разів більше, ніж записів. Якщо це не так, дизайн треба змінити».

Це краще, ніж мовчки вигадувати приховані умови. Інтерв’юер бачить, що ти не продаєш магію, а працюєш з обмеженнями.

5. Практикуй 45-хвилинний формат

Тренування має бути схожим на співбесіду:

1. 5 хвилин — уточнення вимог.
2. 5 хвилин — оцінки.
3. 10 хвилин — API й модель даних.
4. 10 хвилин — високорівнева архітектура.
5. 10 хвилин — масштабування, збої, компроміси.
6. 5 хвилин — підсумок.

Записуй себе на відео або аудіо. Часто проблема не в знаннях, а в тому, що відповідь звучить уривчасто: багато термінів, мало структури.

Типові помилки

1. Починати із технологій

Погано: «Візьмемо Kafka, Redis, Kubernetes, Cassandra».

Добре: «У нас багато подій, їх треба обробляти асинхронно й не втрачати під час піків. Тому потрібна черга повідомлень. Kafka може бути одним із варіантів».

Технологія має бути наслідком вимоги, а не прикрасою.

2. Не уточнювати вимоги

Якщо тобі кажуть спроєктувати пошук, треба з’ясувати: пошук по товарах, документах, людях чи повідомленнях? Потрібні фільтри? Сортування? Виправлення помилок? Миттєве оновлення індексу?

Без цього ти можеш спроєктувати правильну систему для неправильної задачі.

3. Ігнорувати дані

System Design без моделі даних часто виглядає порожньо. Потрібно назвати головні сутності, зв’язки, індекси й патерни читання.

Наприклад, для бронювання квитків ключова проблема — конкурентний доступ до одного місця. Тут треба говорити про транзакції, блокування, унікальні обмеження або резервування з TTL.

4. Обіцяти сильну узгодженість усюди

Сильна узгодженість корисна для грошей, бронювань і прав доступу. Але для лайків, переглядів або стрічки часто достатньо кінцевої узгодженості: дані стануть узгодженими через короткий час.

Якщо вимагати сильну узгодженість усюди, система може стати повільнішою, дорожчою й складнішою.

5. Забувати про збої

Система має працювати не лише на ідеальній дошці. Запитай себе:

• Що буде, якщо база недоступна?
• Що буде, якщо черга накопичить мільйон подій?
• Чи можна повторити операцію без дублікатів?
• Як ми дізнаємося, що система деградує?
• Чи є rate limiting для захисту від надмірних запитів?

Перевір себе

1. Тобі треба спроєктувати скорочувач посилань. Які 3 функціональні й 3 нефункціональні вимоги ти назвеш?
2. У сервісі стрічки новин читань у 50 разів більше, ніж записів. Які компоненти можуть допомогти й чому?
3. Коли краще використати чергу повідомлень, а не виконувати операцію прямо в HTTP-запиті?
4. Чому шардінг бази даних не варто додавати занадто рано?
5. Для системи бронювання місць що важливіше: сильна узгодженість чи максимальна швидкість читання? Чому?

Відповіді

1. Функціональні: створити коротке посилання, перенаправити за кодом, показати статистику. Нефункціональні: швидке читання, висока доступність, стійкість до піків і зловживань.
2. Кеш для популярних стрічок, репліки бази для читання, попереднє формування feed_items, черга для асинхронного оновлення, пагінація.
3. Коли операція повільна, може бути повторена, не потрібна миттєво або має витримувати піки: надсилання email, обробка відео, оновлення пошукового індексу.
4. Шардінг ускладнює запити, транзакції, міграції та операційну підтримку. Спершу варто використати індекси, кеш, репліки й оптимізацію запитів.
5. Сильна узгодженість. Не можна продати або зарезервувати одне місце двом користувачам, навіть якщо це трохи збільшить затримку.

Коротко

• System Design — це проєктування компонентів, даних, потоків, масштабування, збоїв і компромісів.
• На співбесіді важливі не готові схеми, а структура мислення: вимоги, оцінки, API, дані, архітектура, вузькі місця.
• Кеш, черги, реплікація й шардінг потрібні лише тоді, коли вони розв’язують конкретну проблему.
• Добра відповідь завжди містить компроміси: швидкість проти узгодженості, простота проти масштабування, вартість проти надійності.
• Готуйся через практику: розбирай типові системи, рахуй навантаження й тренуй усну відповідь у форматі 45 хвилин.