Навіщо проєктувати системи
Модуль 1Урок 1 з 36Безкоштовний модуль
Уявіть маленький кіоск з морозивом: одна людина приймає гроші, бере ріжок і віддає його клієнту. Усе просто. Тепер уявіть мережу з тисячами кіосків у різних містах, мобільний застосунок, оплату карткою й чергу в години пік. Саме тоді зʼявляється проєктування систем — мистецтво й інженерія того, як зібрати велику систему з частин так, щоб вона працювала швидко, не падала й могла рости.
Що саме ми «проєктуємо»
Проєктування систем — це не про красивий інтерфейс і не про один файл коду. Це про те, які компоненти потрібні (сервери, бази даних, кеш, черги), як вони спілкуються через API, де зберігаються дані й що станеться, якщо щось зламається. Мета — надійна система, корисна для бізнесу й зручна для подальших змін.
Приклад
Застосунок таксі має знайти машину поруч, порахувати ціну, прийняти оплату й показати маршрут. За цим стоять балансувальник навантаження, бази даних із координатами, кеш популярних даних і служби повідомлень. Без проєктування систем ви «просто пишете функції»; із ним — бачите всю картину. Коли водій не отримує замовлення, а клієнт не бачить машину, команда шукає не «одну помилку в React», а розрив між службами розташування, добору водія та надсилання сповіщень.
Коли команда мала, усе можна тримати в голові однієї людини. Коли людей і служб десятки, без спільної картини кожен відповідає за маленький шматочок, а помилки інтеграції зʼявляються там, де блоки не стикуються. Проєктування систем дає мову, щоб обговорювати ці стики до того, як код потрапить у робоче середовище.
Кому це потрібно
Серверному розробнику — щоб масштабувати службу. Розробнику інтерфейсу — щоб розуміти, чому API інколи повільний. Мобільному розробнику — щоб враховувати мережу й збої. Інженеру надійності та підтримці — щоб шукати причину інциденту. Менеджеру — щоб ставити реалістичні вимоги. Навіть якщо ви не проходите співбесіду у великій технологічній компанії, ці ідеї допомагають будувати звичайний продукт, який не «ляже» після першого успіху.
Порада
У цьому курсі ми вживаємо українські назви: балансувальник навантаження, кеш, затримка. Стандартизовані скорочення та власні назви технологій — API, DNS, Redis — лишаються такими, як їх пише документація. Коли ви скажете «тут потрібен кеш», усі зрозуміють, що йдеться про швидкий шар даних, а не про «якусь штуку в памʼяті».
Що запамʼятати
Проєктування систем відповідає на питання «як зібрати велику систему з простих блоків». Воно зʼєднує можливість продукту з архітектурою: не лише «кнопка працює», а «кнопка працює для мільйона людей у різних країнах». Далі ми розберемо ці блоки по одному — простою мовою, з прикладами з реального життя.
Початківці часто думають, що проєктування систем — це лише для «великих компаній». Насправді будь-який продукт, який має рости, рано чи пізно стикається з тими самими питаннями: де зберігати дані, як не перевантажити сервер, що робити під час збою. Краще думати про це раніше, ніж переписувати все після першої вірусної публікації.
Перевірка
3 питанняКілька питань за матеріалом уроку. Спроб — скільки завгодно.