Як мислити ітераціями
Модуль 1Урок 4 з 36Безкоштовний модуль
Реальні системи рідко народжуються ідеальними з першого креслення. Зазвичай створюють простий початковий варіант, вимірюють, знаходять вузьке місце й покращують. Так само варто мислити на курсі й на співбесіді: не шукайте «єдину правильну схему», а рухайтеся кроками.
Два корисні проходи
Перша ітерація (більшість часу): зрозуміти вимоги, намалювати простий потік клієнт → сервер → база, оцінити порядок цифр. Друга: додати те, що ламається під навантаженням — кеш, реплікація, шардування, чергу, CDN. Якщо зʼявляється нова деталь вимог — повертаєтесь і підправляєте дизайн.
Приклад
Стрічка новин: спочатку «читаємо дописи з бази». Потім бачите, що читання надто важке, — додаєте кеш. Далі розумієте, що популярний автор із мільйонами підписників створює перевантажену точку, — думаєте про розсилання допису підписникам і черги. Кожен крок — реакція на вузьке місце. Якби ви одразу намалювали складну схему з десяти служб, то витратили б години на те, що поки не потрібно.
Ітерації не означають «робити погано і потім лагодити». Це означає почати з мінімального робочого дизайну і додавати складність лише там, де вимоги або вимірювання показують потребу. Так ви не переплатите за інфраструктуру на старті і не загубитеся в деталях, які ще не важливі.
Мистецтво припущень
Великі задачі невизначені. Тому ви явно кажете припущення: «100 млн користувачів, 10% щодня активні, середній обʼєкт 100 КБ». Це не брехня — це рамка. Без рамки неможливо обрати базу чи порахувати сховище. Поганий тон — мовчки вигадати цифри й видати їх за факти; хороший — озвучити й за потреби скоригувати.
Порада
На співбесіді часто цінують тих, хто починає з питань і простого скелета, а не з модного набору технологій. Співрозмовник хоче бачити ваш хід думок: як ви уточнюєте вимоги, де бачите ризик, що додаєте далі. Готова промова про Kubernetes без контексту завдання — мінус, а не плюс.
Після кожної ітерації корисно задати собі три питання: що стане вузьке місце при зростанні навантаження в десять разів? Що станеться, якщо один сервер або одна база впаде? Чи можна спростити дизайн, не порушивши NFR? Відповіді часто ведуть до наступного кроку — кеш, реплікація або розбиття на сервіси.
Що запамʼятати
Проєктування систем — ітеративний процес: вимоги → проста схема → оцінки → посилення слабких місць. Далі в курсі ми спочатку навчимося мови NFR і оцінок, потім розберемо блоки, а наприкінці зберемо з них цілі продукти.
Приклад
Стартап з чатом: перша версія — один сервер і PostgreSQL. Через місяць бачите повільні запити до історії — додаєте індекси й кеш останніх повідомлень. Через пів року — шардування по room_id. Кожна ітерація була відповіддю на реальну проблему, а не на уявну «на всяк випадок». Так будують більшість живих продуктів.
Перевірка
3 питанняКілька питань за матеріалом уроку. Спроб — скільки завгодно.