Як платформа працює на GSM CSD, як виявляти і виправляти проблеми у тер. підрозділах.
У 2026 році 99% користувачів працюють на широкосмугових каналах від 100 Мбіт/с. Але для держсектору, охоронних компаній і служб типу МВС залишається сценарій: територіальний підрозділ у віддаленій місцевості з GSM-модемом або супутниковим зв’язком, де доступно 64-128 кбіт/с з high latency. Якщо система не працює там — вона не працює там, де найбільше потрібна.
Сценарії, де повільні канали — норма:
На таких каналах звичайний веб-додаток не працює: сторінка з 5 MB JavaScript завантажується 10 хвилин. UBD спроєктований з врахуванням цих сценаріїв як обов’язкової частини QA.
Кожен HTTP-запит UBD містить мінімум метаданих. Сесійні токени — короткі (JWT з мінімальним claim set). Заголовки — без надлишкових кук.
Типовий запит до API: 200-400 байт overhead + payload. Для порівняння, типовий веб-додаток — 2-5 KB overhead.
HTTP-відповіді стискаються через gzip або brotli. Текстовий JSON стискається у 5-10 разів. Для повільних каналів — це різниця між «прийнятно» і «неможливо».
Налаштування: gzip level 6 — оптимум між CPU overhead і степенем стиснення. Brotli — кращий, але більше CPU; вмикається селективно для критичних endpoints.
На повільних каналах latency запитів — десятки секунд. UBD підтримує batch-API: кілька логічних запитів передаються одним HTTP-запитом. Замість 10 запитів × 5 секунд = 50 секунд, отримуємо 1 запит × 5 секунд = 5 секунд.
При оновленні даних — передається тільки зміни (delta), не повний об’єкт. Якщо документ 1 MB, але змінилось одне поле — передається 100 байт, не 1 MB.
Розробка під повільні канали без емуляції — рецепт катастрофи. У lab-середовищі канал 1 Гбіт/с, система працює ідеально. У полі — 64 кбіт/с з 800 мс latency, система не працює.
Інструменти network shaping:
Базовий тест-сценарій для UBD: 64 кбіт/с, 500 мс latency, 1% packet loss. Якщо ключові операції працюють (вхід, перегляд списку, створення документа за <30 секунд) — система готова.
HTTP-клієнт чекає відповіді 30 секунд, не отримує — кидає помилку. На каналі 64 кбіт/с великий response (100 KB) може передаватися 15+ секунд, що з latency дає 17-20 секунд. Близько до межі.
Рішення: збільшити client-side timeout до 120 секунд для повільних каналів. Дати користувачеві візуальний індикатор: «триває завантаження…».
Канал нестабільний, з’єднання обривається у середині передачі. Користувач отримує половину сторінки. Frontend має це коректно обробляти: повторна спроба завантаження, не відображення проміжного стану.
Рішення: HTTP Range requests, resume на обриві.
Інтерфейс автоматично оновлюється (наприклад, список вхідних повідомлень). На повільному каналі це означає постійне завантаження. Користувач не може зробити іншу операцію.
Рішення: на повільному каналі вимикати auto-refresh. Користувач сам оновлює, коли потрібно.
Завантаження файлу 10 MB на 64 кбіт/с — 25+ хвилин. Цього не уникнути технічно, але треба:
Адміністратор повинен бачити, з якого каналу працюють користувачі. Метрики:
Користувачі, у яких RTT >500 мс або >10% запитів timeout’ять — кандидати на перевірку каналу.
Довідники, метадані моделі, статичні ресурси — кешуються на стороні клієнта на 24 години. На повільному каналі це різниця у 5-10 разів для повторних відвідувань.
Для територіального підрозділу з кількома користувачами — встановлюється локальне проксі-кеш. Воно один раз завантажує статичні ресурси з центру, всі користувачі підрозділу читають з локального кешу.
UBD тестується на 64 кбіт/с з 500 мс latency як обов’язкова частина QA при кожному релізі. Регресія продуктивності на повільному каналі — блокуючий дефект, не «оптимізація на потім». Це закладено у процес розробки з 2018 року, коли перші впровадження у розподілених структурах з територіальними підрозділами виявили цю потребу як критичну.