Надійна архітектура чату підтримки: сесії, статуси присутності та гарантії доставки

Чому типові чати дають збій у критичних бізнес-процесах

У логістиці, доставці та службах підтримки B2B-сервісів чат — це не просто декоративний віджет, а робочий інструмент для координації операцій. Якщо водій чи кур'єр заїжджає у тунель або втрачає зв'язок через розряджений планшет, система не має права показувати його доступним для нових завдань. З іншого боку, повідомлення, надіслані під час відсутності зв'язку, не повинні губитися.

Більшість типових реалізацій на базі базових WebSocket-з'єднань припускаються критичної помилки: покладаються на таймери клієнтського боку. Коли вкладка браузера переходить у фоновий режим або мобільний застосунок засинає, таймери призупиняються. Як наслідок, диспетчер бачить «зелений індикатор», відправляє термінове повідомлення та чекає на відповідь, якої ніколи не буде. Щоб побудувати відмовостійкий сервіс, контроль статусів і доставки необхідно повністю перенести на бекенд.

Оренда присутності (Presence Lease) замість клієнтських статусів

Надійний підхід базується на серверній моделі оренди сесії (lease). Кожен клієнт (користувач, пристрій, кімната) отримує короткоживучий дозвіл на статус присутності з точним терміном завершення:

• Серверний монотонний час: Термін дії оренди перевіряється за серверним годинником, а не за системним часом браузера, який легко спотворюється.
• Регулярний heartbeat з повторною авторизацією: Клієнтський застосунок оновлює оренду частими запитами (heartbeat). Проте кожен запит не просто продовжує час, а повторно верифікує токен сесії та права на кімнату.
• Автоматичне видалення: Якщо фоновий потік оновлення прострочений, сервер без участі клієнта генерує подію відключення користувача.

Така архітектура запобігає стану гонитви (race condition). При цьому статус активності позначає лише факт мережевої доступності сокета, а не прочитання повідомлення співробітником. Розділення цих понять у бізнес-логіці рятує від операційних помилок.

Обробка перепідключень та черга повідомлень

В умовах нестабільного мобільного інтернету будь-яке відновлення зв'язку слід сприймати не як продовження старої сесії, а як нову сесію з окремою авторизацією. Для безшовної роботи потрібні такі механізми:

• Монотонна нумерація: Усі повідомлення всередині кімнати маркуються послідовними числовими індексами (sequence numbers).
• Ідемпотентні ідентифікатори: Кожне повідомлення створюється з унікальним UUID на боці клієнта, що виключає дублювання при повторних спробах надсилання.
• Доначитка історії (Backfill): При перепідключенні клієнт передає останній отриманий індекс. Сервер відправляє лише пропущені повідомлення з черги перед тим, як під'єднати сокет до живого потоку.

Якщо розрив зв'язку тривав занадто довго і черга вийшла за межі збереженого буфера, сервер повинен ініціювати повну синхронізацію кімнати через знімок стану (snapshot), але ніколи не пропускати події мовчки.

Практичні висновки для бізнес-розробки

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