Mobile System Design: коли кодити вже недостатньо

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт, спільното! 👋 Мене звати Анатолій, я Android Tech Lead в N-iX. Останнім часом я помітив чіткий тренд на розповсюдження System Design інтервʼю. Тому вирішив структурувати свої знання та думки у цій публікації.

Стаття буде цікава Mobile-розробникам рівня Middle+, які хочуть прокачати своє архітектурне мислення (але, можливо, ще про це не знають 🙂).

Технічні співбесіди змінилися. Ми перейшли від простих перевірок знань — де ви цитуєте визначення або розв’язуєте маленькі задачі — до масштабних, складних викликів. На передовій цих змін — співбесіда із системного дизайну (System Design Interview).

Цей формат зародився у технологічних гігантах Заходу, але зараз він стає стандартом у всій індустрії, зокрема і в Україні. Тепер це вимога не лише для Staff-архітекторів, а часто й для позицій рівня Middle та Senior. Наприклад, у такій компанії як Revolut.

Розвиток GenAI інструментів для написання коду став каталізатором розповсюдження System Design. Адже тепер можна досить швидко генерувати реалізацію окремих «блоків» інформаційних систем, коли є вимоги та архітектура. І поріг входу, щоб генерувати код, досить низький.

Можна зробити припущення (вже досить популярне), що наступні роки людство буде рухатись в бік оптимізації цієї задачі. Генерувати швидше, більше, якісніше із меншою кількістю людей. Однак задачі, що вимагають системного мислення (проєктування, вирішення технічних компромісів) навряд будуть вирішені так швидко. І це якраз ті задачі, що необхідно розв’язувати на співбесідах з системного дизайну.

Що таке System Design Interview

Зазвичай усе починається із завдання, яке звучить максимально абстрактно. Інтервʼювер може попросити вас: «Спроєктуйте стрічку новин Twitter», «Створіть клон Instagram», або щось більш технічне, наприклад, «Спроєктуйте SDK для аналітики» чи «Бібліотеку для завантаження зображень».

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

Масштаб: за межами застосунку

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

Зазвичай на такому інтервʼю вам потрібно визначити контракт між застосунком і сервером. Тобто необхідно обрати:

• Протоколи комунікації. Ми використовуємо REST, GraphQL, WebSockets чи gRPC? Це повністю залежить від того, будуєте ви чат чи статичну стрічку новин, яка потенційна кількість активних користувачів. Тобто важливі початкові функціональні та нефункціональні вимоги.
• Потік даних. Як дані потрапляють з бази даних на екран користувача і назад? Чи необхідні якісь рівні кешування?
• API Design. Які підходи варто обрати, щоб трафік користувачів не поклав бекенд чи не сповільнив роботу системи?

Чому взагалі варто звертати увагу на System Design

Мобільному розробнику може здатися дивним додавати до сфери своєї відповідальності певну бекенд-частину. Однак хай скільки б незадоволення це не викликало, скасувати цей тренд неможливо.

Ось список причин, з яких, на мою думку, з часом навичка System Design може стати чи не основною:

1. Це новий стандарт. Тренд реальний. Західні компанії використовують це роками, і тепер це стає нормою всюди. Ви, ймовірно, зіткнетеся з цим форматом під час наступного пошуку роботи.
2. Це перевіряє Soft Skills. Така співбесіда схожа на словесний танець. Вона перевіряє, чи можете ви пояснювати складні ідеї, справлятися з невизначеністю та вести технічну дискусію. Це показує, як ви працюєте із задачею, коли шлях на початку незрозумілий.
3. Теорія відходить на другий план. Зазубрювання документації більше не має великої цінності. Розробка стає занадто складною для тримання всіх деталей у голові. Навіть якщо ви добре з цим справляєтеся, сам факт того, що ви відповіли або не відповіли на теоретичне запитання під час інтерв’ю, не означає, що ви класний чи поганий спеціаліст. Тому компанії хочуть бачити ваші навички вирішення проблем — як ви підходите до чогось, чого ніколи раніше не бачили.
4. Фактор ШІ. Це важливо. ШІ стає чудовим у написанні коду та генерації бойлерплейту. Він навіть може спробувати описати архітектуру, виходячи із задачі. Але System Design — це завжди про суб’єктивні компроміси (trade-offs). Чи варто жертвувати консистентністю даних заради швидкодії в умовах поганого інтернету? Чи варто використовувати WebSockets, які висаджують батарею, заради миттєвих повідомлень, якщо це не чат, а стрічка новин? ШІ поки що важко «відчути» ці нюанси контексту. Тому компанії шукають інженерів, які можуть аргументовано обирати «менше з двох зол», а не просто слідувати стандартним кращим практикам.

Як підготуватися до System Design Interview: Фреймворк з трьох етапів

Прийнято розділяти співбесіду з System Design на три етапи:

1. Уточнення вимог.
2. Високорівневий дизайн.
3. Детальне занурення.

Успіх залежить від структури. Поширена помилка — і шлях до провалу — це відразу кидатися в код або малювання діаграм. Не робіть цього. Дотримуйтесь пайплайну.

Етап 1. Уточнення вимог

Це найважливіша частина, оскільки вона одразу задає рамки і тон інтервʼю. Якщо ви вирішуєте не ту проблему, ви провалитеся, незалежно від того, наскільки глибоко ви знаєте технології. Ваша мета тут — визначити межі (scope) і зафіксувати їх.

Для якісного визначення вимог обовʼязково необхідно покрити наступні зони:

• Функціональні вимоги. Виберіть великі, найважливіші функції. Ви не можете побудувати «весь Facebook» за 45 хвилин. Пріоритезуйте! Запитайте: «Ми фокусуємося лише на перегляді стрічки (Feed) чи створення Stories та завантаження медіа також є критичним для MVP?». Це покаже, що ви вмієте відсікати зайве.
• Нефункціональні вимоги. Тут ви показуєте свій професіоналізм. Говоріть про обмеження, як-от:
• Офлайн-режим: чи повинен застосунок працювати без інтернету?
• Безпека: чи потрібно нам шифрувати локальні дані?
• Масштабованість: ми проєктуємо для 1000 користувачів чи для 10 мільйонів?

• Поза межами (Out of Scope): замість того, щоб мовчки ігнорувати частини системи, чітко окресліть межі разом з інтерв’юером.
  • «Чи цікавить нас адмін-панель для модерації контенту, чи ми фокусуємось виключно на клієнтському досвіді?»
  • «Чи можемо ми припустити, що Back-end API вже готовий і надійний, чи мені варто прописати стратегію обробки помилок 5xx?»

Головне правило: це єдиний час для таких фундаментальних запитань.

Не повертайтеся до вимог, коли почнете проєктування. Інакше це виглядатиме хаотично і неструктуровано.

Етап 2. Високорівневий дизайн

Коли межі задачі зрозумілі, переходьте до «великої картини». Ви повинні мислити системою, а не екранами.

• Почніть малювати діаграму. Зобразіть основні блоки. Зазвичай це мобільний клієнт, API Gateway, Load Balancer, CDN та база даних.
• Архітектура застосунку. Почніть наповнювати блок мобільного клієнта основним компонентами: Local data, Network, Push Notifications, і так далі.
• Пояснюйте свої компроміси (Trade-offs). Це серце цього етапу. Ніщо не є очевидним.

• Не використовуйте MVVM просто тому, що це популярно; поясніть, що ви вибрали його, щоб відокремити стан UI від бізнес-логіки.
• Не кажіть просто «ми використаємо базу даних»; поясніть, чому ви вибрали реляційну БД (SQLite/Room) замість NoSQL (Realm).
• Кожен вибір має «за» і «проти». Обґрунтуйте їх на основі вимог!

• Будьте послідовними. Не стрибайте з теми на тему. Слідуйте за потоком даних: почніть з Мережі, перейдіть до Data Layer, потім до бізнес-логіки, і нарешті до UI.

• Говоріть. Тиша — це червоний прапорець. Думайте вголос! Якщо ви малюєте блок для «Image Loader», поясніть, що додаєте його для кешування та зміни розміру зображень поза основним потоком.

Не потрібно заходити у занадто дрібні деталі. Часу на побудову діаграми класів не вистачить. Крім того, глибока деталізація може заплутати інтервʼювера. Ваша задача показати спроможність побудови цілісної системи. Якщо інтервʼювера зацікавить глибший рівень деталізації, він вас про це спитає.

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

Ідеальної схеми не існує. Завжди можна щось додати чи намалювати інакше. І це нормально, якщо ви бажаєте щось намалювати по-своєму. Однак найголовніше — це виконати задачу: донести ваше бачення інтервʼюверу. Якщо ви намалювали «ідеальну» схему, але не встигли все покрити чи схема вийшла занадто складною для розуміння — задача не виконана.

Етап 3. Детальне занурення (Deep Dive)

Після того, як високорівневий дизайн узгоджено, інтерв’юер вибере конкретні області для детального розбору. Це вже буде більше схоже на формат технічних інтервʼю, до яких ми звикли.

Однак напрям запитань може бути дуже різним. Фактично будь-який блок на діаграмі може викликати зацікавленість у інтервʼювера. Одні з типових областей для занурення:

• Синхронізація даних. Як застосунок поводитиметься при «поганому» інтернеті? Що станеться, якщо користувач лайкне пост в офлайні, а потім відредагує його з іншого пристрою? (Тут варто згадати про Conflict Resolution та Optimistic UI).
• Робота з медіа. Як ефективно завантажувати тисячі картинок у стрічці? (Resizing на стороні CDN, in-memory cache, disk cache, pre-fetching).
• Продуктивність UI (Main Thread). Як гарантувати 60 (або 120) FPS при складному рендерингу? Винесення обчислень у background workers, DiffUtil (Android) / DiffableDataSource (iOS).
• Енергоефективність. Як застосунок впливає на батарею? (Batching аналітичних подій, відмова від постійного геолокаційного трекінгу).
• Безпека. Де зберігати токени (KeyChain/Keystore)? Чи використовуємо Certificate Pinning?

Можна спробувати вгадати, на чому може бути фокус залежно від компанії.

• Стрімінгові застосунки (Netflix, YouTube) запитають про пропускну здатність, кешування та буферизацію.
• Фінтех-застосунки (Revolut, Stripe) зосередяться на безпеці та цілісності даних.
• Соціальні мережі сфокусуються на пагінації стрічки та плавному скролінгу.

Ключі до успіху

Успішна співбесіда із системного дизайну — це не ідеальна діаграма за 45 хвилин. Це демонстрація конкретних інженерних навичок:

• Робота з невизначеністю: чи можете ви перетворити розмитий запит («Спроєктуйте стрічку») на конкретний план?
• Структуроване мислення: ви підходите до проблем крок за кроком чи хаотично?
• Чітка комунікація: чи можете ви коротко пояснити свої думки?
• Відповідальність за рішення: чи берете ви відповідальність за свої рішення? Чи можете ви підкріпити свій вибір аргументами та захистити свої компроміси?

Що робити

На сьогоднішній день є багато теоретичних матеріалів із System Design. Відеопроходження таких інтервʼю, статті, курси. Є навіть ціла серія книг. Тож можна легко почати опановувати теоретичний матеріал.

Однак, практика — це головне. Читання статей чи книжок допомагає, але ви повинні практикуватися. Мок-інтерв’ю з колегами — найкращий спосіб симулювати стрес. А стресу під час system design interview багато. Вам треба структуровано думати, говорити з інтервʼювером, записувати чи малювати схему. І все це одночасно. Без належної практики впоратись із таким навантаженням нереально.

На мою думку, у світі, де ШІ може писати код, здатність проєктувати системи — це конкурентна перевага.

Корисні ресурси

• MSD Framework: GitHub Repository
• Статті: ProAndroidDev Series
• Мок-інтерв’ю: FaangInterviewUa Telegram

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.