Системний дизайн мобільних застосунків зазвичай асоціюється з екранами, архітектурними патернами та UX. Але на співбесідах усе частіше питають інше: як саме застосунок спілкується з бекендом, що відбувається з даними, коли немає мережі, як поводяться медіафайли, де зберігаються токени й як команда розуміє, що відбувається в продакшені. У своєму гайді з мобільного системного дизайну розробник і автор каналу Philipp Lackner розкладає ці рішення на конкретні технічні вибори, які очікують від інженера рівня middle–senior.
Цей матеріал зосереджений саме на «нижньому шарі» мобільного системного дизайну: протоколи, API, схема даних, офлайн‑first, медіа, безпека та спостережуваність. Це ті речі, які відрізняють простий клієнт до REST‑API від продуманого мобільного продукту, здатного працювати в реальних умовах — зі слабкою мережею, обмеженою батареєю та мільйонами користувачів.
REST, WebSockets, SSE чи GraphQL: як вибір протоколу змінює застосунок
На рівні діаграми все виглядає просто: «клієнт говорить із сервером». Але системний дизайн починається там, де з’являється запитання «як саме?». Для мобільних застосунків це не абстрактна деталь, а фундаментальне рішення, яке впливає на батарею, затримки, стабільність і навіть UX.
Найочевидніший варіант — REST поверх HTTP. Класична модель: застосунок робить HTTP‑запит, сервер відповідає, з’єднання закривається. Для більшості CRUD‑операцій цього достатньо: отримати профіль, оновити налаштування, завантажити список постів. Простота, зрозумілі інструменти, величезна екосистема.
Проблеми починаються, коли продукт вимагає реального часу. Соціальна стрічка, чат, лайви, нотифікації — усе це спокушає до наївного рішення: «давайте просто опитувати сервер у циклі». Технічно це працює: клієнт кожні N секунд робить GET‑запит до REST‑ендпойнта, перевіряє, чи є нові події, оновлює UI. Але з погляду мобільного системного дизайну це майже завжди поганий компроміс.
Постійне опитування REST‑ендпойнтів створює зайве навантаження на мережу, витрачає батарею й усе одно не дає справжнього «реального часу». Якщо інтервал занадто великий, користувач бачить затримки; якщо занадто малий — пристрій гріється, а бекенд отримує лавину запитів, більшість з яких повертають «нічого нового».
Тут у гру вступають WebSockets і server‑sent events (SSE). Обидва підходи дозволяють тримати довготривале з’єднання між клієнтом і сервером, але з різною семантикою. WebSocket — двосторонній канал: клієнт і сервер можуть надсилати повідомлення один одному в будь‑який момент. Це природний вибір для чатів, ігор, спільного редагування. SSE — односторонній потік від сервера до клієнта, коли саме сервер пушить події, а клієнт лише слухає. Для стрічок, нотифікацій чи оновлень статусу цього часто достатньо, і реалізація простіша.
Ключова ідея: замість того, щоб клієнт постійно питав «чи є щось нове?», сервер сам повідомляє про події, коли вони стаються. Це зменшує кількість запитів, краще масштабується й, за умови коректної реалізації, економить батарею.
Окремою лінією йде GraphQL. Це не стільки про реальний час, скільки про гнучкість даних. Якщо REST‑ендпойнти повертають фіксовані структури, то GraphQL дозволяє клієнту описати, які саме поля потрібні. Для мобільних застосунків це критично, коли один і той самий бекенд обслуговує різні платформи й екрани: замість «товстих» відповідей, де половина полів не використовується, клієнт може запитати рівно те, що потрібно для конкретного екрану. Це зменшує трафік і прискорює рендеринг.
У системному дизайні мобільного застосунку вибір між REST, WebSockets, SSE та GraphQL — не питання «модності», а відповідь на конкретні вимоги: чи потрібен реальний час, наскільки важливі оптимізація трафіку, простота кешування, стабільність з’єднання в умовах мобільної мережі. На співбесіді від кандидата очікують не назви технологій, а аргументований вибір і розуміння компромісів.
API та схема даних: профіль, стрічка, пагінація й соціальний граф
Щойно визначено протокол, наступний шар системного дизайну — це власне API й схема даних. Для мобільного розробника це не лише «документація бекенда», а частина професійної відповідальності: як виглядають ендпойнти, які параметри вони приймають, як організовано пагінацію, які таблиці стоять за цими запитами.
Уявімо типовий соціальний застосунок. Мінімальний набір функцій — профіль користувача, стрічка постів, можливість підписуватися, коментувати. На рівні API це перетворюється на зрозумілі ендпойнти: наприклад, GET /profile для отримання профілю, GET /feed для завантаження стрічки. Але важливо не лише «що» повертає ендпойнт, а й «як».
Стрічка — класичний приклад, де без пагінації система не виживе. Сотні чи тисячі постів не можуть завантажуватися одним запитом. Тому в системному дизайні одразу закладається механізм посторінкового завантаження. Поширений підхід — курсорна пагінація: клієнт передає курсор (ідентифікатор останнього отриманого елемента або спеціальний токен) і ліміт — скільки елементів потрібно повернути. Бекенд відповідає наступним «шматком» стрічки й, за потреби, новим курсором.
Для мобільного застосунку це не просто оптимізація. Пагінація дозволяє плавно підвантажувати контент під час скролу, зменшує час першого відображення екрана, дає змогу кешувати частини стрічки локально. На рівні співбесіди очікується, що кандидат одразу закладе курсор і ліміт у дизайн API, а не спробує «якось потім оптимізувати».
Під API завжди стоїть схема даних. У тому ж соціальному прикладі мінімальний набір таблиць виглядає передбачувано, але саме його потрібно вміти проговорити. Таблиця users з базовими полями профілю. Таблиця posts, де кожен запис належить одному користувачу, але один користувач може мати довільну кількість постів. Таблиця comments, де кожен коментар прив’язаний до конкретного поста, а пост може мати багато коментарів. Таблиця follows, яка описує, хто на кого підписаний: один користувач може мати багато підписників, і водночас сам підписуватися на багатьох.
Ці зв’язки формують соціальний граф і безпосередньо впливають на те, як формується стрічка, як рахуються лічильники, як працюють рекомендації. Для мобільного розробника важливо розуміти, що дизайн API й схема даних — це не «чорний ящик бекенда», а частина загального системного дизайну, де клієнт і сервер мають бути узгоджені.
Offline‑first і локальний кеш: коли телефон — головне джерело правди
Мобільні застосунки живуть у світі нестабільної мережі. Потяги, тунелі, ліфти, роумінг, обмежений трафік — усе це робить підхід «онлайн‑або‑нічого» дедалі менш прийнятним. Звідси — популярність offline‑first‑підходу, який у системному дизайні змінює саму модель роботи з даними.
Ключовий принцип offline‑first — локальний кеш як єдине джерело правди. Застосунок у першу чергу читає дані з локального сховища, а не з мережі. Бекенд стає джерелом синхронізації, а не обов’язковою умовою для роботи. Користувач відкриває стрічку — застосунок показує те, що є в локальній базі, а в бекграунді оновлює дані з сервера. Користувач редагує профіль — зміни спершу потрапляють у локальне сховище, а потім синхронізуються.
Такий підхід різко покращує сприйняття швидкості: екрани відкриваються миттєво, навіть якщо мережа «просідає». Але ціна — складність синхронізації. Поки застосунок працює лише на одному пристрої, модель «локальний кеш + бекграунд‑синк» ще можна тримати відносно простою. Справжні проблеми починаються, коли в гру входять кілька пристроїв.
Якщо один і той самий користувач редагує ті самі дані офлайн на різних пристроях, система неминуче стикається з конфліктами. Один телефон змінює ім’я профілю, інший — аватар, обидва роблять це без мережі, а потім виходять в онлайн у різний час. Або складніший сценарій: два пристрої змінюють одне й те саме поле по‑різному. Без явної стратегії розв’язання конфліктів дані будуть перезаписуватися в непередбачуваному порядку.
У системному дизайні offline‑first‑застосунку конфлікт‑резолюшн — не деталь реалізації, а обов’язковий елемент. Потрібно визначити, що вважається «правильним» у разі розбіжностей: остання зміна за часом, пріоритет певного пристрою, мерж окремих полів, ручне вирішення користувачем. Кожен варіант має наслідки для UX і складності бекенда.
Для мобільного розробника це означає, що локальна база, кеш‑шари, черги змін і механізми синхронізації — повноцінні частини системного дизайну. На співбесіді очікують, що кандидат не лише скаже «ми кешуємо дані локально», а й пояснить, як застосунок поводиться без мережі, як відбувається синк і що трапляється, коли кілька пристроїв змінюють одні й ті самі дані.
Медіа: великі файли, chunked‑завантаження й кешування зображень
Щойно в застосунку з’являються фото, відео чи великі документи, системний дизайн стикається з обмеженнями мобільних пристроїв. Пам’ять, мережа, батарея — усе це робить роботу з медіа окремим блоком рішень.
Один із ключових викликів — завантаження великих файлів. На десктопі можна дозволити собі прочитати файл цілком у пам’ять і відправити одним запитом. На мобільному пристрої з обмеженим обсягом RAM це ризиковано: великий відеофайл може просто не вміститися, а паралельні операції — призвести до крашів.
Тому в системному дизайні мобільних застосунків для великих медіа зазвичай закладають chunked‑завантаження. Файл розбивається на менші частини, кожна з яких завантажується окремо. Це дозволяє контролювати споживання пам’яті, відновлювати завантаження після обриву мережі, розподіляти навантаження. Застосунок може трекати прогрес по чанках, повторно відправляти лише ті, що не дійшли, і не тримати весь файл у пам’яті.
Зворотний бік — завантаження медіа з сервера. Тут у гру вступає кешування зображень на клієнті. Без нього кожен скрол стрічки перетворюється на десятки однакових запитів до тих самих URL, зайвий трафік і помітні затримки. Кешування дає змогу зберігати зображення локально й повторно використовувати їх при повторному показі. Це не лише економія трафіку, а й відчутне покращення сприйняття швидкості.
Для системного дизайну важливо, що рішення щодо медіа приймаються не «в кінці», а на рівні загальної архітектури: як організовано API для завантаження, чи підтримує бекенд chunked‑upload, як клієнт керує чергою завантажень, що відбувається при втраті мережі, як довго й де зберігається кеш зображень. Усе це безпосередньо впливає на стабільність, батарею й досвід користувача.
Безпека: токени, шифрування, HTTPS і обмеження zero‑knowledge
Безпека в мобільному системному дизайні — це не лише «додати HTTPS». Йдеться про повний ланцюжок: як користувач автентифікується, де й як зберігаються токени, які дані шифруються, що може побачити сервер.
Починається все з токенів доступу. Мобільний застосунок неминуче зберігає деяку форму облікових даних — access‑токен, refresh‑токен чи інші секрети, які дозволяють відновити сесію без повторного логіну. Системний дизайн має передбачити безпечне сховище для цих токенів, а не простий SharedPreferences чи локальний файл у відкритому вигляді. На Android і iOS існують спеціальні механізми захищеного зберігання, і їх використання — не «бонус», а базова вимога.
Наступний шар — шифрування даних. HTTPS для всіх мережевих запитів сьогодні де‑факто стандарт, але системний дизайн може піти далі й зашифрувати чутливі дані в локальному сховищі. Це особливо актуально для застосунків, які працюють із приватним контентом, фінансами, здоров’ям.
Найрадикальніший варіант — zero‑knowledge‑підхід, коли сервер технічно не може прочитати вміст користувацьких даних. У такій моделі шифрування й дешифрування відбуваються виключно на клієнті, а бекенд бачить лише зашифровані блоки. Це значно підвищує приватність, але різко обмежує можливості бекенда: стає складно робити пошук по вмісту, рекомендації, серверні фільтри, аналіз даних.
У системному дизайні мобільного застосунку zero‑knowledge — це не просто «галочка про безпеку», а фундаментальне архітектурне рішення. Воно визначає, які операції можливі на сервері, як виглядає схема даних, як організовано синхронізацію між пристроями. Від розробника очікують розуміння, що кожен додатковий рівень безпеки має ціну — у складності, продуктивності, функціональності.
Спостережуваність після релізу: краші, аналітика, перформанс і A/B‑тести
Системний дизайн мобільного застосунку не закінчується в момент публікації в сторі. Після релізу починається етап, де без спостережуваності продукт фактично «сліпий». Для мобільних команд це особливо критично: оновлення проходять через модерацію, користувачі не оновлюються миттєво, а відкат версії — нетривіальна операція.
Базовий інструмент — репортинг крашів. Без нього команда не бачить, де й у яких умовах застосунок падає на реальних пристроях. Системний дизайн має передбачити інтеграцію сервісів, які збирають стеки помилок, прив’язують їх до версій, пристроїв, сценаріїв використання. Це дозволяє пріоритизувати виправлення й уникати повторення критичних помилок.
Другий шар — аналітика. Йдеться не про маркетингові дашборди, а про розуміння того, як користувачі реально взаємодіють із функціями. Які екрани відкриваються найчастіше, де користувачі «відвалюються», як часто використовуються ті чи інші можливості. Для системного дизайну це означає, що події аналітики закладаються ще на етапі планування фіч, а не додаються хаотично «після».
Третій компонент — моніторинг продуктивності. Час запуску, затримки мережевих запитів, споживання пам’яті, частота ANR — усе це впливає на рейтинги в сторах і утримання користувачів. Інструменти перформанс‑моніторингу дозволяють побачити, як зміни в коді чи конфігурації впливають на реальну роботу застосунку на різних пристроях і в різних мережах.
Над цим шаром будуються механізми віддаленої конфігурації й A/B‑тестування. Remote config дозволяє змінювати поведінку застосунку без оновлення через стор: вмикати чи вимикати фічі, змінювати пороги, перемикати експериментальні алгоритми. A/B‑тестування дає змогу порівнювати різні варіанти UX, алгоритмів або налаштувань на реальних користувачах, поступово розкочуючи вдалі зміни.
Усе це — частина постдеплойментної стратегії, яка в сучасному системному дизайні вважається обов’язковою. На співбесіді мобільного розробника дедалі частіше питають не лише «як ви реалізуєте фічу», а й «як ви зрозумієте, що вона працює добре в продакшені й що робитимете, якщо ні».
Висновок: системний дизайн — це про узгоджені рішення, а не про «правильний стек»
Мобільний системний дизайн часто подають як набір патернів і технологій. Але якщо подивитися на нього через призму бекенда, даних, офлайн‑first, медіа, безпеки й спостережуваності, стає очевидно: це радше про послідовні рішення й компроміси.
Вибір між REST, WebSockets, SSE та GraphQL визначає, як застосунок поводиться в реальному часі й як витрачає батарею. Дизайн API й схема даних задають межі масштабованості й можливості клієнта. Offline‑first із локальним кешем як єдиним джерелом правди дає швидкість і стійкість до поганої мережі, але вимагає продуманого конфлікт‑резолюшну. Стратегія роботи з медіа впирається в обмеження пам’яті й мережі. Рівень безпеки, включно з потенційним zero‑knowledge, визначає, що взагалі може робити бекенд. А спостережуваність після релізу перетворює застосунок із «запакованого продукту» на живу систему, яку можна вимірювати й покращувати.
Для мобільного розробника, який готується до системних співбесід або будує складний продукт, це означає одне: потрібно мислити не лише екранами й архітектурними шарами, а й тим, як застосунок живе в екосистемі бекенда, мережі, пристрою й реального світу користувачів.
Джерело
Beginner’s Guide to Mobile App System Design (+ Tips for Interviews!)