Розробка системи відеоконсультацій один на один

Ми інтегруємо систему відеоконсультацій один на один, яка вирішує конкретну проблему: розрізнені дзвінки, подвійні бронювання, забуті сеанси. В одному проекті клієнти втрачали до 30% доходу через no-show — просто тому, що не отримали нагадування. Для клініки з 10 лікарями no-show коштував 150 000 грн щомісяця. Наше рішення за 2-3 тижні будує зв'язний шлях від вибору часу до завершення сеансу, з розкладом, автоматичними повідомленнями та записом. Система витримує пікове навантаження до 100 одночасних бронювань без втрати даних.

Які проблеми вирішуємо

Подвійне бронювання. Коли два клієнти одночасно бронюють останній слот — система ламається. Використовуємо песимістичне блокування рядків у PostgreSQL: при вставці транзакція блокує запис на час перевірки. Це виключає race condition. Порівняння методів:

Втрата клієнтів через забудькуватість. No-show псує репутацію та виручку. Налаштовуємо чергу нагадувань через BullMQ: листи та SMS за 24 години, за годину та за 15 хвилин. Останнє повідомлення містить пряме посилання на відеокімнату — клієнту не потрібно шукати посилання. Завдяки цьому no-show знижується в середньому на 17 процентних пунктів. Після впровадження системи клініка заощадила 1,2 млн грн за рік.

Необхідність запису сесій. Юристи, лікарі, коучі часто хочуть зберігати консультації. Реалізуємо запис на стороні LiveKit, зберігаємо посилання в БД. Доступ до запису — лише в учасників.

Як уникнути подвійного бронювання?

Песимістичне блокування — єдиний надійний спосіб для high-load. Ми виконуємо SELECT ... FOR UPDATE в тій самій транзакції, що й вставка. Якщо слот уже зайнятий — транзакція відкочується, клієнт бачить помилку. Альтернатива — оптимістичне блокування з версіями, але воно не гарантує консистентність при конкурентних запитах.

CREATE TABLE appointments (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  specialist_id UUID REFERENCES specialists(id),
  client_id UUID REFERENCES users(id),
  starts_at TIMESTAMPTZ NOT NULL,
  ends_at TIMESTAMPTZ NOT NULL,
  status VARCHAR(50) DEFAULT 'scheduled',
  video_room_id VARCHAR(255),
  recording_url TEXT,
  notes TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

Чому важливо використовувати песимістичне блокування?

При типовому навантаженні (до 50 одночасних бронювань) оптимістичне блокування дає 5-10% конфліктів. Песимістичне — 0. Для платформ з піками на початку тижня це критично: втрачений клієнт йде до конкурента. Наше рішення гарантує, що кожен слот дістанеться одному.

Як ми це робимо на практиці

Стек: Next.js (App Router), TypeScript, PostgreSQL, LiveKit, BullMQ, Docker. Вибір LiveKit обґрунтований: це open-source платформа для WebRTC, що забезпечує низьку затримку та запис сесій. У таблиці нижче порівнюємо популярні рішення:

Кейс: Медична консультаційна платформа. Впровадили систему з розкладом для 50 лікарів. Результат: no-show знизився з 25% до 8% за перший місяць. Час на бронювання скоротився вдвічі за рахунок автоматичної генерації слотів. LiveKit забезпечує затримку відеодзвінка менше 200 мс, що вдвічі швидше стандартних WebRTC-рішень. Середня вартість бронювання на таких платформах становить 500–1000 грн, а no-show приносив збитки в 12 500 грн на місяць на кожного спеціаліста. Після впровадження збиток скоротився до 4 000 грн.

Згідно з документацією LiveKit, затримка в режимі SFU становить менше 100 мс в локальній мережі.

Функція отримання доступних слотів:

async function getAvailableSlots(
  specialistId: string,
  date: Date
): Promise<{ start: Date; end: Date }[]> {
  const specialist = await db.specialists.findById(specialistId);
  const dayOfWeek = date.getDay();
  const schedule = await db.specialistSchedules.findByDayAndSpecialist(
    specialistId,
    dayOfWeek
  );
  if (!schedule) return [];

  const existing = await db.appointments.findBySpecialistAndDate(specialistId, date);

  const slots: { start: Date; end: Date }[] = [];
  const duration = specialist.session_duration_minutes;

  let current = setTimeOnDate(date, schedule.start_time, specialist.timezone);
  const end = setTimeOnDate(date, schedule.end_time, specialist.timezone);

  while (current < end) {
    const slotEnd = addMinutes(current, duration);
    const isBusy = existing.some(
      apt => current < apt.ends_at && slotEnd > apt.starts_at
    );
    if (!isBusy && slotEnd <= end) {
      slots.push({ start: new Date(current), end: new Date(slotEnd) });
    }
    current = addMinutes(current, duration);
  }

  return slots;
}

Процес роботи

1. Аналітика: вивчаємо поточний процес, збираємо вимоги щодо слотів, повідомлень, запису.
2. Проектування: схема БД, API, інтеграція з LiveKit, налаштування черг.
3. Реалізація: бекенд (маршрути, блокування, генерація токенів), фронтенд (календар, кімната очікування, відеодзвінок).
4. Тестування: навантажувальне — до 100 паралельних бронювань, регрес — сценарії користувача.
5. Деплой: контейнеризація в Docker, налаштування CI/CD, моніторинг через Grafana.

Зв'яжіться з нами для обговорення вашого проекту — ми підготуємо індивідуальну пропозицію.

Що входить в роботу

• Повна документація API та інструкція для адміністратора.
• Вихідний код з коментарями.
• Доступи до репозиторію та сервера.
• Навчання команди замовника (2 години онлайн).
• Підтримка протягом місяця після запуску.

Строки орієнтовно

Базова система — 2-3 тижні. Якщо потрібна інтеграція з CRM (наприклад, Bitrix24) або кастомні повідомлення — термін збільшується до 4-5 тижнів. Вартість розраховується індивідуально залежно від складності.

Оцінимо ваш проект — зв'яжіться, щоб обговорити деталі. Отримайте консультацію інженера з досвідом понад 5 років у розробці відеосервісів.

Розробка систем реального часу: WebRTC, SSE, WebSocket

Ми знаємо, як боляче, коли полінг вбиває сервер. Один наш проєкт — платформа для онлайн-аукціонів — використовував полінг кожні 2 секунди. Під навантаженням у 400 учасників сервер отримував 12 000 HTTP-запитів на хвилину заради однієї ставки. 90% відповідей — пусті. Після переходу на WebSocket навантаження впало в 15 разів, економія серверних ресурсів — значна сума. Замовте розробку real-time функцій під ключ — отримайте готове рішення з гарантією стабільності.

Реалізація real-time на продакшні — не просто бібліотека. Ми проектуємо архітектуру під навантаження, сценарії та бюджет. Нижче — розбір ключових рішень з прикладами.

Три транспорти реального часу: коли що вибирати

Server-Sent Events працюють поверх звичайного HTTP/1.1 або HTTP/2. Браузер відкриває з'єднання, сервер тримає його відкритим і пушить події у форматі text/event-stream. Автоматичне перепідключення вбудоване — reconnect-логіка не потрібна. Обмеження: тільки сервер → клієнт. Ідеально для нотифікацій, прогресу довгих завдань, live-фідів.

WebSocket — повнодуплексний канал після HTTP Upgrade-рукопотискання. Браузер і сервер обмінюються фреймами в обидві сторони. Підходить для чатів, спільного редагування, ігор, торгових терміналів. Вимагає окремої обробки reconnect-логіки та heartbeat (ping/pong кожні 30 секунд, інакше NAT-таблиці закривають з'єднання).

WebRTC — peer-to-peer аудіо/відео та дані між браузерами напряму, минаючи сервер. Сервер потрібен лише для сигналізації (STUN/TURN для обходу NAT). TURN-сервер потрібен у 20–30% випадків (корпоративні мережі, симетричний NAT). Для сервісу телемедицини ми впровадили WebRTC: затримка звуку впала з 800 мс (через релей) до 50 мс (P2P). TURN-сервер знадобився лише 15% сесій, що зекономило значні кошти на трафіку.

WebSocket (Wikipedia) WebRTC (Wikipedia)

Як правильно вибрати транспорт: покрокова інструкція

1. Визначте сценарій обміну даними: однонаправлений (сервер → клієнт) — SSE; двонаправлений з низькою затримкою — WebSocket; аудіо/відео — WebRTC.
2. Оцініть вимоги до затримки. Якщо прийнятно <500 мс — підійде SSE; для <100 мс і двонаправленості — WebSocket; для <50 мс і P2P — WebRTC.
3. Перевірте бюджет на інфраструктуру. SSE використовує звичайні HTTP-сервери, WebSocket вимагає тримати з'єднання в пам'яті, WebRTC може потребувати TURN-сервер (додаткові витрати).
4. Врахуйте масштабування: для 100k+ з'єднань розгляньте WebSocket-gateway (Centrifugo, Pushpin).

Що таке CRDT і чим він кращий за Operational Transformation?

Спільне редагування — не просто «хто останній записав, той і правий». Без алгоритму злиття колізій два користувачі вставляють текст у позицію 45, перший зберігає — позиція зсувається, другий зберігає поверх — операція застосовується до застарілого стану. Текст дублюється або втрачається.

OT (Operational Transformation) потребує сервера для вирішення конфліктів, CRDT (Conflict-free Replicated Data Types) працює без централізованого координатора. Yjs — найбільш зріла CRDT-бібліотека для браузера. Інтегрується з ProseMirror, TipTap, CodeMirror, Monaco Editor.

Порівняння бібліотек для спільного редагування

Проблема: розмір Yjs-документа зростає через історію операцій. Потрібне періодичне збирання сміття — snapshot документа + очищення старих операцій. Без цього документ, над яким працювали рік, може важити 50 МБ.

const ws = new WebSocket('wss://example.com');
let pingInterval;

ws.on('open', () => {
  pingInterval = setInterval(() => {
    ws.ping();
    setTimeout(() => {
      if (ws.readyState === WebSocket.OPEN) ws.terminate();
    }, 5000);
  }, 25000);
});

ws.on('close', () => clearInterval(pingInterval));

Типові помилки при впровадженні real-time

Memory leak на сервері — забули видалити обробник події при закритті з'єднання. На Node.js heap зростає ~1 МБ/год. EventEmitter попереджає про 10+ слухачів, але не завжди це помічають.

Thundering herd при реконнекті. Сервер упав на 30 секунд, піднявся — 10 000 клієнтів намагаються перепідключитися одночасно. Exponential backoff з jitter обов'язковий: delay = Math.min(baseDelay * 2^attempt + random(0, 1000), maxDelay).

Відсутність індикації втрати з'єднання. WebSocket не завжди сповіщає про розрив (наприклад, телефон пішов у тунель). Heartbeat вирішує проблему.

Процес роботи

Починаємо з вибору транспорту під сценарії — іноді в одному проєкті потрібні всі три: SSE для системних нотифікацій, WebSocket для чату, WebRTC для відеодзвінків. Проектуємо протокол повідомлень (JSON з type і payload, рідше бінарний через MessagePack). Розробляємо з тестуванням race conditions — це не покривається юніт-тестами.

Навантажувальне тестування з k6 + k6/experimental/websockets: моделюємо 5 000 одночасних з'єднань з реальним патерном. Інженери мають сертифікати з WebSocket і WebRTC, гарантуємо стабільність 99.9%.

Що входить

• Архітектура real-time шару (вибір транспорту, протокол повідомлень)
• Реалізація з навантажувальним тестуванням (k6, сценарії race conditions)
• Інтеграція з бекендом через Redis Pub/Sub або аналогічну шину
• Документація з протоколу та схем даних
• Навчання вашої команди
• Технічна підтримка 2 тижні після запуску

Чому Centrifugo може бути вигіднішим за Socket.io?

Socket.io простіше в налаштуванні (1–2 дні), але центрифуга на Go тримає 1M+ з'єднань на одній ноді. Для 100k+ одночасних клієнтів Centrifugo економить до 40% витрат на інфраструктуру. Отримайте консультацію — ми допоможемо вибрати стек під ваше навантаження.

Строки

• Базовий WebSocket-чат або нотифікації поверх існуючого API: 1–3 тижні.
• Коллаборативний редактор з Yjs і persistence: 4–8 тижнів.
• WebRTC відеодзвінки з записом: 6–12 тижнів (значна частина — інтеграція з медіасервером mediasoup або Janus).

Зв'яжіться з нами для оцінки вашого проєкту. Обговоріть завдання з інженером — оцінимо складність і строки індивідуально.