Системний дизайн у світі мобільних застосунків давно перестав бути темою лише для бекенд‑інженерів. Від Android‑та iOS‑розробників на співбесідах усе частіше очікують, що вони зможуть спроєктувати умовний WhatsApp, Instagram чи YouTube — не на рівні макетів екранів, а як цілісну систему. У свіжому гайді розробник Philipp Lackner пропонує просту, але показову модель: дивитися на мобільний system design через три рівні «зуму» — від продуктового бачення до архітектури й конкретного техстеку.

Ця трирівнева оптика допомагає не лише краще будувати реальні застосунки, а й значно впевненіше почуватися на співбесідах, де просять «спроєктувати Instagram». Йдеться не про відтворення реальної інфраструктури Meta, а про демонстрацію структурованого мислення, вміння бачити компроміси та аргументувати вибір.
Рівень 1: продуктове бачення — хто користується і що саме робить застосунок
Перший рівень зуму — це погляд з висоти пташиного польоту. Тут ще немає жодних класів, ендпоінтів чи баз даних. Є лише базові, але критичні запитання: для кого створюється застосунок, що він робить і в яких умовах ним користуються.
Ключова точка старту — користувацька база. Вік, технічна обізнаність, типи пристроїв, професія, географія — усе це безпосередньо впливає на дизайн системи. Якщо цільова аудиторія — старші користувачі, доводиться закладати зовсім інші принципи UX: простіші інтерфейси, «дурневитривалі» сценарії, менше прихованих жестів і складних налаштувань. До цього додається й технічний аспект: старші люди частіше користуються старими Android‑пристроями, тож підтримка давніших версій ОС і обмежених ресурсів стає не побажанням, а вимогою.
Географія й мови теж не зводяться до простого «додати локалізацію». Якщо застосунок працює лише для іспаномовної аудиторії в одній країні, набір припущень щодо мережевих умов, платіжних систем чи правових обмежень буде одним. Якщо ж це глобальний продукт із підтримкою англійської, німецької, арабської та інших мов, доводиться думати про праворуч‑наліво верстку, культурні відмінності, різні часові пояси та формати даних.
Окремий вимір — професія. Застосунок «для всіх» і застосунок «для архітекторів» — це різні світи. Коли відомо, що продукт орієнтований на конкретну професійну групу, можна робити сміливіші припущення: рівень цифрової грамотності, типові робочі процеси, специфічні дані, з якими працюють користувачі. Це впливає як на набір функцій, так і на те, як глибоко потрібно продумувати, наприклад, офлайн‑режим чи роботу з великими файлами.
Після відповіді на запитання «для кого» неминуче постає «що саме» — тобто перелік функцій. На цьому етапі важливо не скочуватися в абстракції, а чітко розкласти застосунок на функціональні блоки. Для умовної соціальної мережі це може бути профіль, стрічка, система підписок, список друзів, редагування профілю, вбудований редактор постів.
Кожна така функція далі розкладається на конкретні функціональні вимоги: профіль дозволяє завантажувати фото, змінювати ім’я користувача, зберігати приховану електронну пошту; стрічка показує пости лише від тих, на кого підписаний користувач; редактор постів підтримує текст, зображення, відео. Це опис того, що застосунок має робити, без прив’язки до того, як саме це реалізовано.
Поруч із функціональними вимогами стоїть цілий пласт нефункціональних — і саме вони часто визначають технічні рішення. Тут ідеться не про «що», а про «як»: обмеження на час запуску, розмір APK, допустиму затримку мережі, споживання батареї, вимоги до продуктивності, пам’яті, локалізації, масштабування.
Якщо, наприклад, встановлено жорстке обмеження на споживання батареї, це автоматично впливає на рішення щодо реального часу: постійно відкриті з’єднання, важка обробка медіа, агресивний бекграунд‑ворк стають проблемними. Якщо очікується активне використання застосунку «в полі» — у транспорті, з періодичними втратами зв’язку, — доводиться закладати іншу модель роботи з мережею, ніж у випадку, коли більшість користувачів сидить на стабільному Wi‑Fi.
Мобільні пристрої додають ще один критичний параметр — пам’ять. Робота з великими файлами, наприклад відео, змушує думати про розбиття завантажень на частини, щоб не тримати весь файл у пам’яті. До цього додаються вимоги до швидкості запуску, загальної продуктивності, затримок у мережі, а також до масштабування: скільки користувачів має витримати система, скільки даних припадає на одного користувача, як це позначиться на клієнтській частині.
Усе це — перший рівень зуму. Тут ще не обирають конкретні бібліотеки, але вже формують рамки, у яких доведеться працювати архітектурі й техстеку.
Рівень 2: архітектура — як організувати код і відповідальності
Другий рівень зуму переносить фокус із продуктового бачення на внутрішню структуру застосунку. Йдеться про те, як організований код, які шари й патерни використовуються, як застосунок взаємодіє з зовнішніми сервісами.
Перший блок рішень — інтеграції. Якщо це чат‑застосунок, неминуче постає питання окремого сервісу для обміну повідомленнями. Якщо є авторизація, потрібно визначити, як саме працює логін: через рефреш‑токени, одноразові паролі, двофакторну автентифікацію. Якщо планується аналітика, варто заздалегідь вирішити, які саме події логувати, як це вплине на приватність і продуктивність. Профільні дані можуть приходити з окремого сервісу, що теж потрібно врахувати в загальній схемі.
Другий блок — власне архітектурний каркас. Тут вирішується, наскільки складною має бути внутрішня структура. Для невеликого застосунку з обмеженим масштабом іноді достатньо двошарової моделі: UI‑шар і data‑шар. Це спрощує розробку й зменшує оверхед, якщо зрозуміло, що кодова база не виросте до гігантських розмірів.
Якщо ж майбутнє продукту невизначене, а потенціал зростання великий, доводиться закладати більш серйозні архітектурні принципи. Тут у гру входять патерни на кшталт MVVM чи MVI у презентаційному шарі, підхід «чистої архітектури» з чітким розділенням доменних, дата‑ та UI‑шарів, використання use case‑інтерфейсів і репозиторіїв як абстракцій над джерелами даних.
MVVM і MVI по‑різному організовують потоки даних між UI та логікою, але в обох випадках ідеться про те, щоб зробити поведінку передбачуваною, тестованою й масштабованою. Чиста архітектура додає до цього жорсткіші кордони між шарами, що дозволяє легше змінювати, наприклад, джерело даних (локальне сховище, REST‑API, WebSocket) без переписування бізнес‑логіки.
Use case‑підхід допомагає явно формалізувати бізнес‑операції — «отримати стрічку», «оновити профіль», «надіслати повідомлення» — і відокремити їх від деталей реалізації. Репозиторій, у свою чергу, інкапсулює роботу з різними джерелами даних, дозволяючи, наприклад, комбінувати локальний кеш і мережу, не засмічуючи цим UI‑код.
На цьому рівні також приймаються рішення про те, як саме застосунок взаємодіє з бекендом. Сам факт, що потрібен сервер, ще нічого не говорить про протокол чи модель обміну даними. Саме тут визначається, чи достатньо класичного REST поверх HTTP, чи потрібні WebSocket‑з’єднання, чи варто дивитися в бік GraphQL або server‑sent events.
Архітектурний рівень — це про те, щоб створити каркас, який витримає нефункціональні вимоги з першого рівня зуму й не перетвориться на хаос при зростанні продукту. Водночас він має залишатися настільки простим, наскільки це можливо в конкретних умовах: надмірна складність без реальної потреби так само шкодить, як і повна її відсутність.
Рівень 3: техстек — протоколи, API, схеми даних і кешування
Третій рівень зуму — найдетальніший. Тут уже йдеться про конкретні технологічні рішення: які протоколи використовувати, як виглядає API, яку схему має база даних, де й як застосовується кешування.
Один із ключових блоків — вибір протоколу для комунікації з сервером. Класичний варіант — REST поверх HTTP: клієнт надсилає запит, сервер відповідає. Це універсальний і добре зрозумілий підхід, але він не завжди оптимальний, особливо коли потрібен реальний час.
Спроба емулювати реальний час через REST‑polling — коли клієнт у циклі надсилає запити до сервера, щоб «оновити дані» — швидко виявляється неефективною. Це створює зайве навантаження на мережу, збільшує затримки й, що критично для мобільних пристроїв, суттєво б’є по батареї. У таких сценаріях логічно дивитися в бік WebSocket‑з’єднань або server‑sent events, де сервер може сам повідомляти клієнта про нові події. Це дозволяє досягти справжнього реального часу без постійного опитування.
GraphQL додає ще один вимір гнучкості. Якщо відповіді REST‑ендпоінтів виходять занадто «товстими», а клієнту щоразу потрібна лише частина даних, GraphQL дозволяє запитувати рівно те, що потрібно. Для мобільного це може означати менші обсяги трафіку й кращу продуктивність, особливо в умовах нестабільного зв’язку.
Ще один важливий аспект техстеку — дизайн API. Тут вирішується, які саме ендпоінти існують, які параметри вони приймають, як реалізована пагінація. Для тієї ж соціальної мережі це може бути ендпоінт профілю для отримання даних користувача, ендпоінт стрічки для завантаження постів. Пагінація часто реалізується через параметри на кшталт cursor і limit, що дозволяє завантажувати стрічку частинами, а не тягнути сотні елементів за один раз. Це знову ж таки безпосередньо впливає на продуктивність, споживання пам’яті й мережеві витрати.
На рівні даних постає питання схеми бази. Для соціального застосунку типовим буде набір таблиць на кшталт users, posts, comments, follows із чітко визначеними зв’язками. Один користувач може мати багато постів, але кожен пост належить лише одному користувачу. Один пост може мати багато коментарів, але кожен коментар прив’язаний до конкретного поста. Таблиця підписок описує, хто на кого підписаний, причому один користувач може мати багато підписників, і кожен підписник може стежити за багатьма користувачами. Такі правила задаються саме на рівні системного дизайну, а не «по ходу» реалізації.
Окремий пласт — політики даних і кешування. Потрібно вирішити, де застосунок зберігає локальний кеш, що вважається «джерелом істини», як поводитися при відсутності мережі. Підхід offline‑first із локальним кешем як єдиним джерелом істини дозволяє зробити застосунок стійкішим до проблем зі зв’язком, але різко ускладнює синхронізацію й розв’язання конфліктів, коли кілька пристроїв змінюють одні й ті самі дані офлайн. Це вже тема для окремої розмови, але на рівні техстеку важливо хоча б окреслити, чи застосунок узагалі йде в цей бік.
Технічні рішення на цьому рівні також включають стратегії завантаження й вивантаження медіа, роботу з великими файлами, кешування зображень на клієнті, безпекові аспекти на кшталт зберігання токенів, шифрування, використання HTTPS або більш жорстких моделей, де сервер не має доступу до вмісту користувача. Після релізу додається ще один шар — спостережуваність: краш‑репорти, аналітика, моніторинг продуктивності, віддалена конфігурація, A/B‑тестування. Усе це теж частина системного дизайну, але вже на стику мобільного клієнта й інфраструктури.
Навіщо це все на співбесіді: не «вгадати WhatsApp», а показати мислення
Усе описане вище може звучати як план реального проєкту, але в контексті співбесід важливий інший акцент. Коли кандидата просять «спроєктувати WhatsApp» чи «зробити дизайн Instagram», від нього не очікують точного відтворення продакшн‑архітектури цих гігантів. Справжня мета — побачити, як людина мислить на трьох рівнях зуму.
На продуктовому рівні важливо, чи вміє кандидат ставити запитання про користувачів, сценарії використання, обмеження середовища, а не одразу малює схему мікросервісів. На архітектурному — чи може він обґрунтувати вибір патернів, розділення шарів, інтеграцій, виходячи з вимог, а не з моди. На рівні техстеку — чи розуміє компроміси між REST і WebSocket, між товстими відповідями й GraphQL, між простим кешем і складним offline‑first, між зручністю й безпекою.
System design для мобільних розробників у цьому сенсі — не про енциклопедичні знання всіх можливих технологій, а про структуроване міркування. Три рівні зуму — зручна ментальна модель, яка допомагає не загубитися в деталях і не пропустити критичні рішення. Вона дозволяє послідовно рухатися від «для кого й навіщо» до «як це організувати в коді» й «які саме технології для цього обрати».
Висновок: системний дизайн як базова компетенція мобільного розробника
Мобільний system design дедалі більше стає обов’язковою компетенцією для Android‑ та iOS‑інженерів. Від них очікують не лише вміння писати якісний UI‑код, а й здатності мислити категоріями продукту, архітектури й техстеку одночасно.
Модель із трьома рівнями зуму — продуктове бачення, архітектура, техстек — дає зрозумілу рамку для таких рішень. Вона допомагає будувати застосунки, які враховують реальних користувачів і їхні обмеження, мають стійку внутрішню структуру й спираються на обґрунтований вибір технологій. А на співбесідах ця ж модель дозволяє показати головне — вміння мислити системно й бачити компроміси, а не просто знати останні тренди в мобільних фреймворках.
Джерело
Beginner’s Guide to Mobile App System Design (+ Tips for Interviews!)