Питання на співбесіді з System Design з відповідями

Приклади запитань

Кілька запитань із кожного рівня з правильною відповіддю й поясненням.

System Design · Junior

1. Що відбувається, коли користувач вводить адресу сайту й натискає Enter?

   Правильна відповідь: DNS → з'єднання (TCP/TLS) → HTTP-запит → відповідь → рендеринг сторінки

   Браузер знаходить IP через DNS (з кешами на всіх рівнях), встановлює з'єднання й TLS-рукостискання, надсилає запит, отримує HTML, розбирає його, завантажує CSS/JS/картинки, будує DOM і CSSOM, виконує layout і paint. Це класичне запитання для початку розмови про продуктивність.

2. Для чого потрібна система DNS?

   Правильна відповідь: Перекладає доменні імена в IP-адреси серверів

   DNS - розподілений «телефонний довідник» інтернету. Відповіді кешуються (браузер, ОС, провайдер) на час TTL. Шифрування - задача TLS, копії контенту ближче до користувача - задача CDN.

3. Чим HTTPS відрізняється від HTTP?

   Правильна відповідь: Трафік шифрується, а справжність сервера перевіряється через TLS

   TLS захищає від прослуховування й підміни даних, а сертифікат підтверджує, що ви говорите зі справжнім сервером. Багато сучасних API браузера (Service Worker, геолокація, HTTP/2 у браузерах) працюють лише по HTTPS.

4. Що означає принцип REST «ресурси + HTTP-методи»?

   Правильна відповідь: URL позначає ресурс, а метод - дію: GET /users/1, DELETE /users/1

   REST використовує іменники в URL і семантику методів HTTP: GET - читання, POST - створення, PUT/PATCH - оновлення, DELETE - видалення. Так API стає передбачуваним, а кеші й проксі розуміють сенс запитів.

System Design · Middle

1. З чого правильно починати відповідь на задачу з frontend system design?

   Правильна відповідь: З уточнення вимог і обмежень

   Популярний каркас RADIO: Requirements (функціональні й нефункціональні), Architecture (компоненти й потоки даних), Data model (клієнтський стан), Interface (API), Optimizations (продуктивність, a11y, i18n, безпека). Без вимог легко спроєктувати не ту систему.

2. Чим курсорна пагінація краща за пагінацію за зсувом (offset) для стрічки?

   Правильна відповідь: Немає дублів під час вставлень і швидко на глибоких сторінках

   За offset нові пости зсувають вибірку, і користувач бачить повтори; OFFSET 100000 дорогий для БД. Курсор («після запису з id X») стабільний і ефективний за індексом. Мінус - не можна стрибнути на сторінку 57, тому для таблиць із номерами сторінок offset іноді доречніший.

3. Як спроєктувати нескінченну стрічку з тисячами постів?

   Правильна відповідь: Курсорне довантаження за IntersectionObserver і віртуалізація списку

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

4. Що важливо врахувати під час проєктування автодоповнення (autocomplete)?

   Правильна відповідь: Debounce, скасування застарілих запитів, кеш, клавіатуру

   Плюс мінімальна довжина запиту, обробка гонок відповідей, підсвічування збігів, стан «нічого не знайдено», ARIA-патерн combobox. Для невеликого фіксованого словника допустимо фільтрувати на клієнті (іноді з trie), для великих - серверний пошук.

System Design · Senior

1. Що стверджує теорема CAP?

   Правильна відповідь: Під час мережевого розділення доводиться обирати між узгодженістю та доступністю

   Consistency, Availability, Partition tolerance: розділення мережі в розподіленій системі неминуче, і в цей момент система або відмовляє частині запитів (CP), або відповідає, можливо, застарілими даними (AP). У звичайній роботі компроміс - між узгодженістю та затримкою (PACELC).

2. Користувач оновив профіль, перезавантажив сторінку й побачив старі дані. Яку гарантію порушено?

   Правильна відповідь: Read-your-writes: користувач має бачити власні зміни

   Типова причина - читання з репліки, на яку зміна ще не доїхала, або застарілий кеш. Рішення: читати «свої» дані з основного вузла деякий час після запису, оновлювати клієнтський кеш відповіддю мутації, використовувати updateTag замість SWR-інвалідації.

3. Чим небезпечний вибір ключа шардування «за датою створення»?

   Правильна відповідь: Усі нові записи потраплять в один шард - вийде гаряча партиція

   Шардування розподіляє дані між вузлами; ключ має рівномірно розподіляти навантаження й відповідати запитам. Монотонний ключ концентрує запис в останньому шарді. Часто використовують хеш від id користувача або складений ключ.

4. Навіщо консистентне хешування під час додавання вузлів кешу?

   Правильна відповідь: Під час зміни кількості вузлів переміщується лише невелика частка ключів

   З hash(key) % N зміна N перерозподіляє майже всі ключі, і кеш масово промахується. Кільце хешів (з віртуальними вузлами) переміщує лише ~1/N ключів. Використовується в розподілених кешах, CDN, базах даних.

Збірні тести з цією темою

Запитання з кількох тем одразу - як на співбесіді на конкретну вакансію.