Стандарти, інформація, автономний режим і моніторинг

Системний дизайн мобільних застосунків зазвичай асоціюється з роботою над екранами, архітектурними патернами та UX. Проте на співбесідах дедалі частіше зосереджуються на інших аспектах: як саме застосунок взаємодіє з бекендом, що відбувається з даними за відсутності мережі, як керуються медіафайли, де зберігаються токени, та яким чином команда відстежує ситуацію у продакшені. У своєму детальному гайді з мобільного системного дизайну розробник і автор каналу Philipp Lackner розкриває ці технічні рішення, які дають уявлення про очікувані навички інженера рівня middle–senior.

---

Цей матеріал концентрується на «нижньому рівні» мобільного системного дизайну, що включає:

• протоколи зв’язку;
• API і структуру даних;
• offline-first підхід;
• роботу з медіа;
• безпеку;
• спостережуваність застосунку.

Саме ці елементи відрізняють простого клієнта до REST‑API від ретельно продуманого мобільного продукту, здатного функціонувати у реальному світі зі слабким зв’язком, обмеженою батареєю та великою кількістю користувачів.

---

REST, WebSockets, SSE чи GraphQL: вибір протоколу та його вплив на застосунок

На загальній діаграмі взаємодія клієнта та сервера виглядає просто – «клієнт спілкується із сервером». Однак системний дизайн починається з питання: «Як саме це відбувається?». Для мобільних застосунків це не просто технічна тонкість, а ключове рішення, що впливає на енергоспоживання, затримки, стабільність зв’язку та користувацький досвід.

1. REST поверх HTTP – класична модель, де застосунок робить HTTP-запит, отримує відповідь, а з’єднання закривається. Цей підхід оптимальний для більшості CRUD-операцій: отримання профілю, оновлення налаштувань, завантаження стрічки постів. Його переваги: простота, зрозумілі інструменти та велика екосистема.

2. Проблеми при роботі в реальному часі. Соціальні стрічки, чати, live-трансляції та нотифікації часто спокушають обирати циклічне опитування серверу через REST. З технічної точки зору це працює: клієнт робить GET-запити з певним інтервалом, оновлює UI за наявності нових подій. Однак:

   • Таке рішення підвищує навантаження на мережу.
   • Збільшує витрати батареї.
   • Не забезпечує дійсного режиму «реального часу».

   Занадто рідкі запити призводять до затримок, тоді як дуже часті – перегрівають пристрій і створюють лавину запитів на сервер, більшість яких є непотрібними.

3. WebSockets і Server-Sent Events (SSE). Обидва протоколи дозволяють підтримувати тривале з’єднання між клієнтом і сервером:

   • WebSocket — двонаправлений канал, де і клієнт, і сервер можуть ініціювати обмін повідомленнями в будь-який час. Ідеально підходить для чатів, ігор та спільного редагування.

   • SSE — односторонній канал від сервера до клієнта, що дозволяє серверу «пушити» події, а клієнт лише їх слухає. Зазвичай достатньо для соціальних стрічок, нотифікацій та оновлень статусу, реалізація при цьому простіша.

4. Головна ідея: замість того, щоб клієнт постійно питав, чи є нові дані, сервер оповіщає про події в момент їхньої появи. Це знижує кількість запитів, покращує масштабованість і, за умови коректної реалізації, сприяє економії батареї.

5. GraphQL не стільки про реальний час, скільки про гнучкість роботи з даними. На відміну від REST, де ендпоїнти повертають фіксовану структуру, GraphQL дозволяє клієнту самостійно визначати, які саме поля потрібні. Це особливо корисно для мобільних застосунків, які обслуговують різні платформи та екрани. Переваги:

   • Замість «товстих» відповідей, де половина полів не використовується, запит містить лише необхідні дані.
   • Зменшується обсяг трафіку.
   • Прискорюється рендеринг інтерфейсу.

Таким чином, вибір між REST, WebSockets, SSE і GraphQL вирішується не на основі модних трендів, а з урахуванням конкретних вимог: чи потрібен режим реального часу, наскільки важлива оптимізація трафіку, простота кешування і стабільність роботи в умовах мобільної мережі. На співбесідах очікують від кандидатів аргументований вибір із розумінням відповідних компромісів.

---

API та структура даних: профілі, стрічка, пагінація і соціальні зв’язки

Після вибору протоколу наступний рівень системного дизайну – це розробка API та організація схеми даних. Для мобільного розробника це більше, ніж проста документація бекенда – це ключова професійна відповідальність.

Для прикладу візьмемо типовий соціальний застосунок з такими функціями:

• профіль користувача;
• стрічка постів;
• підписки та коментарі.

На рівні API це реалізується через зрозумілі ендпоїнти, наприклад:

• GET /profile – для отримання профілю користувача;
• GET /feed – для завантаження стрічки.

Однак важлива не лише інформація, яку повертає ендпоїнт, а й спосіб її отримання.

• Пагінація – обов’язковий механізм для стрічки, адже завантажувати сотні чи тисячі постів одним запитом неможливо. Найпоширеніший метод – курсорна пагінація, коли клієнт передає:

  • курсор (ідентифікатор останнього отриманого елемента або спеціальний токен);
  • ліміт – кількість записів, які потрібно отримати.

Сервер у відповіді надсилає наступну порцію даних і новий курсор (за потреби).

Переваги пагінації для мобільних додатків:

• плавне підвантаження контенту під час скролу;
• швидше відображення першої сторінки;
• можливість локального кешування частин стрічки.

На співбесідах очікують, що кандидат з початку передбачить використання курсорної пагінації та ліміту в API, а не залишатиме це «на потім» для оптимізації.

• Схема даних формує основу системи. У випадку соціальної мережі мінімум таблиць має виглядати так:

  1. users – з базовими полями профілю;
  2. posts – кожен запис належить одному користувачу, але користувач може мати багато постів;
  3. comments – коментарі прив’язані до постів;
  4. follows – описує підписки між користувачами (один користувач може мати багато підписників і водночас бути підписаним на інших).

Ці взаємозв’язки формують соціальний граф, що безпосередньо впливає на формування стрічки, підрахунок лічильників та алгоритми рекомендацій. Важливо усвідомлювати, що API і схема даних – це не «чорний ящик» бекенда, а узгоджена частина загального системного дизайну, яка забезпечує ефективну взаємодію клієнта і сервера.

---

Offline-first підхід і локальний кеш: телефон як головне джерело даних

Мобільні застосунки працюють у середовищі нестабільного зв’язку. Транспорт, тунелі, ліфти, роумінг і обмежений трафік ускладнюють застосування моделі «тільки онлайн». Тому offline-first підхід набуває дедалі більшої популярності та трансформує модель роботи з інформацією.

Основні принципи offline-first:

• локальний кеш є головним джерелом правди;
• застосунок спершу читає дані з локального сховища, а не з мережі;
• бекенд виконує роль джерела синхронізації, а не примусової умови роботи.

Наприклад:

• користувач відкриває стрічку – час відображення даних мінімальний, адже застосунок показує те, що вже є в кеші, а у фоновому режимі оновлює інформацію з сервера;
• редагування профілю перш за все зберігається локально і потім синхронізується.

Такий підхід суттєво підвищує враження від швидкості та надійності. Але він водночас ускладнює синхронізацію даних, особливо коли користувач використовує кілька пристроїв.

• Коли одна і та сама особа редагує одні й ті самі дані офлайн на різних девайсах, виникають конфлікти:

  • наприклад, один пристрій змінює ім’я профілю, інший – аватар;
  • складніші випадки – дві різні зміни одного поля.

Без продуманого підходу дані можуть перезаписуватися в довільному порядку.

• У системному дизайні offline-first застосунку механізм розв’язання конфліктів (conflict resolution) є ключовим:

  • визначення правил пріоритету змін (останній час, пріоритет пристрою тощо);
  • можливість об’єднання змін на рівні полів;
  • або ручне втручання користувача у складних випадках.

Кожне рішення має наслідки для користувацького досвіду і складності бекенда.

Для мобільного розробника це означає, що:

• локальна база даних;
• кеш-шари;
• черги змін;
• механізми синхронізації

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

---

Медійні файли: великі об’єми, поетапне завантаження та кешування

Як тільки у застосунок вводяться великі медіафайли – фотографії, відео, документи – системний дизайн мусить брати до уваги специфіку мобільних пристроїв:

• обмежену оперативну пам’ять;
• нестабільне мережеве з’єднання;
• обмеження батареї.

Ключові виклики пов’язані з завантаженням великих файлів:

• На десктопі можливо прочитати файл цілком у пам’ять і відправити його одним запитом.
• На мобільних пристроях це ризиково через обмежений обсяг ОЗП і потенційні збої.
• Сам файл може не вміститись у пам’ять, а паралельні операції можуть викликати крахи.

Для подолання цих проблем у системному дизайні мобільних застосунків застосовується chunked-завантаження:

• файл ділиться на менші частини;
• кожна завантажується окремо;
• це дає змогу контролювати використання пам’яті, відновлювати процес після мережевих обривів;
• черговість підвантаження і повторна відправка пропущених фрагментів підвищують стабільність.

З іншого боку, при завантаженні медіа з сервера критично важливе кешування зображень:

• без нього кожне повторне скролювання стрічки створювало б десятки однакових запитів;
• це перевантажує канал зв’язку і викликає помітні затримки при візуалізації;
• кешування дозволяє зберігати зображення локально та повторно їх використовувати.

Рішення щодо медіа повинні враховувати не тільки реалізацію на рівні UI, а й загальну архітектуру – від організації API для завантаження, підтримки chunked-upload бекендом, управління чергами завантажень, поведінки при втратах мережі, до тривалості і місця зберігання кешу. Всі ці аспекти суттєво впливають на стабільність роботи, споживання енергії і користувацький досвід.

---

Безпека: управління токенами, шифрування, HTTPS та zero-knowledge підходи

Безпека мобільного системного дизайну охоплює:

• автентифікацію користувача;
• захищене зберігання токенів доступу;
• шифрування даних;
• дотримання сучасних протоколів.

Початковий рівень безпеки – це токени доступу, які мобільний додаток зберігає для підтримки сесії без повторного логіну:

• access-токен;
• refresh-токен;
• інші секретні ключі.

Системний дизайн повинен забезпечити їх захищене зберігання, адже прості сховища типу SharedPreferences або локальні файли у відкритому вигляді не прийнятні. На платформах Android і iOS існують спеціалізовані механізми захищеного зберігання, використання яких є базовою вимогою.

Далі йде шифрування даних. HTTPS для передачі мережевих запитів — сьогодні стандарт, але в деяких випадках доцільно захистити чутливу інформацію і на локальному рівні, особливо для застосунків, пов’язаних з приватною інформацією, фінансами чи здоров’ям.

Найбільш радикальний підхід – zero-knowledge модель, коли сервер технічно не має доступу до користувацьких даних у відкритому вигляді. Шифрування і дешифрування відбуваються виключно на стороні клієнта, а сервер зберігає тільки зашифровані об’єкти. Це підвищує приватність, але ускладнює функціональність бекенда, обмежуючи:

• можливість пошуку;
• рекомендацій;
• серверних фільтрів;
• аналізу даних.

Zero-knowledge у системному дизайні – це архітектурне рішення, яке впливає на структуру даних, роботу з синхронізацією і набір можливостей сервера. Важливо розуміти, що кожен рівень безпеки має ціну в складності, швидкодії та функціональності.

---

Спостережуваність після запуску: краші, аналітика, продуктивність і A/B-тестування

Системний дизайн не завершується після публікації застосунку в магазині. Після релізу починається новий етап, на якому відсутність належної спостережуваності робить продукт фактично «сліпим».

Особливості мобільної розробки:

• оновлення проходять модерацію;
• користувачі оновлюють додаток не миттєво;
• відкат версій складний.

Базові інструменти, які повинні бути включені в системний дизайн:

1. Репортинг крашів – дає змогу бачити, де і за яких обставин застосунок аварійно завершує роботу. Це допомагає пріоритизувати виправлення та уникати повторення критичних помилок.

2. Аналітика – не маркетингове відстеження, а розуміння поведінки користувачів:

   • які екрани відкриваються найчастіше;
   • де користувачі втрачають інтерес;
   • які функції використовуються активніше за все.

Аналітичні події мають бути закладені ще на стадії планування функціоналу, а не додаватися хаотично пізніше.

1. Моніторинг продуктивності – показники запуску, затримки мережевих запитів, використання пам’яті, частота ANR впливають на рейтинг в сторах і утримання користувачів. Інструменти моніторингу дозволяють оцінити, як зміни в коді або налаштування впливають на роботу застосунку у різних умовах.

2. Віддалена конфігурація і A/B-тестування представляють собою наступний рівень:

   • Remote Config дозволяє вмикати або вимикати функції, змінювати параметри, переключати алгоритми без оновлення через магазин.
   • A/B-тестування дає змогу порівнювати альтернативні версії UX, алгоритмів чи налаштувань на реальних користувачах, поступово впроваджуючи успішні зміни.

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

---

Системний дизайн мобільних застосунків варто сприймати не як набір патернів та технологій, а як сукупність зважених стратегічних виборів та компромісів. Вплив різних технологій на функціональність та ресурсоспоживання:

• Вибір між REST, WebSockets, SSE і GraphQL визначає поведінку застосунку в режимі реального часу та використання батареї.
• Архітектура API та структура даних задають масштабованість і функціональні рамки клієнта.
• Offline-first із локальним кешем забезпечує швидкість та стійкість при нестабільному з’єднанні, але вимагає складних алгоритмів врегулювання конфліктів.
• Стратегії роботи з медіа ускладнюються обмеженнями пам’яті і каналу зв’язку.
• Рівень безпеки, включно з zero-knowledge моделями, визначає можливості та обмеження бекенда.
• Спостережуваність після релізу трансформує застосунок із простого продукту в живу систему, що піддається вимірюванню та поліпшенню.

Для фахівців, які готуються до системних співбесід або розробляють складні продукти, це означає необхідність мислити ширше за межі екранів і архітектурних патернів — враховувати взаємодію застосунку з екосистемою бекенда, мережею, пристроями та реальним середовищем користувачів.

---

Джерело матеріалу:
Beginner’s Guide to Mobile App System Design (+ Tips for Interviews!)