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

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

Проста форма запису не враховує реальну зайнятість спеціаліста. Подвійне бронювання, плутанина з часовими поясами, забудькуватість клієнтів — типові проблеми. За статистикою, до 30% записів зриваються через відсутність нагадувань, а при пікових навантаженнях (1000+ запитів на хвилину) ймовірність конфлікту зростає до 15%. Наприклад, для однієї мережі медичних центрів ми створили систему, що обробляє до 500 запитів на секунду з нульовим відсотком конфліктів. Ми вирішуємо ці проблеми на рівні архітектури: песимістичні блокування, автоматична конвертація часових поясів та багаторівневі нагадування. У цій статті розповімо, як побудувати надійну систему бронювання відеоконсультацій, синхронізовану з Google Calendar, зі сповіщеннями та захистом від конфліктів.

Проблеми, які вирішуємо

Перша — гонка запитів: два клієнти одночасно обирають один слот. Без блокувань обидва отримали б підтвердження. Ми використовуємо песимістичні блокування на рівні PostgreSQL, що виключає race condition. PostgreSQL гарантує атомарність транзакції з FOR UPDATE NOWAIT.

Друга — часові пояси. Клієнт у Києві, спеціаліст у Нью-Йорку. Система автоматично конвертує час через timestamptz та користувацьку таймзону. Жодних ручних розрахунків.

Третя — нагадування. Без них до 30% записів зриваються. Ми налаштовуємо email та push-сповіщення за 24 години та за годину до консультації.

Четверта — скасування або перенесення бронювання. Без вбудованих механізмів виникають проблеми з синхронізацією календарів та поверненням коштів. Наше API підтримує повний цикл управління записами.

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

В основі — транзакція з блокуванням рядків FOR UPDATE NOWAIT. При спробі бронювання ми перевіряємо перетин інтервалів у таблиці bookings. Якщо слот зайнятий — повертаємо 409 Conflict.

app.post('/api/bookings', authenticate, async (req, res) => {
  const { specialistId, startsAt, durationMinutes } = req.body;
  const endsAt = addMinutes(new Date(startsAt), durationMinutes);

  try {
    const booking = await db.transaction(async (trx) => {
      const conflict = await trx.query(
        `SELECT id FROM bookings
         WHERE specialist_id = $1
           AND status = 'confirmed'
           AND tstzrange(starts_at, ends_at) && tstzrange($2::timestamptz, $3::timestamptz)
         FOR UPDATE NOWAIT`,
        [specialistId, startsAt, endsAt.toISOString()]
      );

      if (conflict.rows.length > 0) {
        throw Object.assign(new Error('Slot taken'), { code: 'CONFLICT' });
      }

      const [booking] = await trx.query(
        `INSERT INTO bookings (specialist_id, client_id, starts_at, ends_at)
         VALUES ($1, $2, $3, $4) RETURNING *`,
        [specialistId, req.user.id, startsAt, endsAt.toISOString()]
      );

      return booking;
    });

    await syncToGoogleCalendar(booking);
    await sendBookingConfirmation(booking, req.user);
    await notifySpecialist(booking, req.user);
    await scheduleReminders(booking);

    res.json(booking);
  } catch (err: any) {
    if (err.code === 'CONFLICT') {
      return res.status(409).json({ error: 'Slot is no longer available' });
    }
    throw err;
  }
});

Як синхронізувати розклад з Google Calendar?

Використовуємо OAuth2 та офіційний клієнт googleapis. Після створення бронювання автоматично створюється подія в календарі спеціаліста з конференц-посиланням. При скасуванні — подія видаляється. Це економить час і виключає помилки.

import { google } from 'googleapis';

async function syncToGoogleCalendar(booking: Booking) {
  const specialist = await db.specialists.findById(booking.specialist_id);
  if (!specialist.google_calendar_token) return;

  const oauth2Client = new google.auth.OAuth2(
    process.env.GOOGLE_CLIENT_ID,
    process.env.GOOGLE_CLIENT_SECRET
  );
  oauth2Client.setCredentials(specialist.google_calendar_token);

  const calendar = google.calendar({ version: 'v3', auth: oauth2Client });

  const client = await db.users.findById(booking.client_id);

  const event = await calendar.events.insert({
    calendarId: 'primary',
    requestBody: {
      summary: `Консультація з ${client.name}`,
      start: { dateTime: booking.starts_at.toISOString() },
      end: { dateTime: booking.ends_at.toISOString() },
      attendees: [{ email: client.email }],
      conferenceData: {
        createRequest: { requestId: booking.id },
      },
    },
    conferenceDataVersion: 1,
  });

  await db.bookings.update(booking.id, { google_event_id: event.data.id });
}

Структура даних та алгоритм пошуку слотів

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

CREATE TABLE availability_schedules (
  id UUID PRIMARY KEY,
  specialist_id UUID REFERENCES specialists(id),
  day_of_week SMALLINT NOT NULL,  -- 1=Mon ... 7=Sun
  start_time TIME NOT NULL,
  end_time TIME NOT NULL,
  is_active BOOLEAN DEFAULT true
);

CREATE TABLE availability_overrides (
  id UUID PRIMARY KEY,
  specialist_id UUID REFERENCES specialists(id),
  date DATE NOT NULL,
  type VARCHAR(50),  -- 'blocked' | 'custom_hours'
  start_time TIME,
  end_time TIME
);

CREATE TABLE bookings (
  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 'confirmed',
  cancel_reason TEXT,
  google_event_id VARCHAR(255),
  created_at TIMESTAMPTZ DEFAULT now()
);

async function getAvailableSlots(
  specialistId: string,
  date: string,
  durationMinutes: number,
  userTimezone: string
): Promise<Array<{ start: string; end: string }>> {
  const localDate = new Date(`${date}T00:00:00`);
  const dayOfWeek = getISODayOfWeek(localDate);

  const schedule = await db.query<{ start_time: string; end_time: string }>(
    `SELECT start_time, end_time FROM availability_schedules
     WHERE specialist_id = $1 AND day_of_week = $2 AND is_active = true`,
    [specialistId, dayOfWeek]
  );

  if (!schedule.rows.length) return [];

  const override = await db.query(
    `SELECT * FROM availability_overrides
     WHERE specialist_id = $1 AND date = $2`,
    [specialistId, date]
  );

  if (override.rows[0]?.type === 'blocked') return [];

  const workStart = override.rows[0]?.start_time ?? schedule.rows[0].start_time;
  const workEnd = override.rows[0]?.end_time ?? schedule.rows[0].end_time;

  const booked = await db.query<{ starts_at: string; ends_at: string }>(
    `SELECT starts_at, ends_at FROM bookings
     WHERE specialist_id = $1
       AND DATE(starts_at AT TIME ZONE $3) = $2
       AND status = 'confirmed'`,
    [specialistId, date, userTimezone]
  );

  const slots: Array<{ start: string; end: string }> = [];
  let current = parseTime(date, workStart, userTimezone);
  const end = parseTime(date, workEnd, userTimezone);

  while (current < end) {
    const slotEnd = addMinutes(current, durationMinutes);
    if (slotEnd > end) break;

    const isBusy = booked.rows.some(b =>
      current < new Date(b.ends_at) && slotEnd > new Date(b.starts_at)
    );

    if (!isBusy) {
      slots.push({
        start: current.toISOString(),
        end: slotEnd.toISOString(),
      });
    }

    current = addMinutes(current, durationMinutes);
  }

  return slots;
}

Компонент вибору часу на React

Користувач обирає дату, система підвантажує доступні слоти. Інтерфейс адаптивний і працює на мобільних.

function BookingCalendar({ specialistId, durationMinutes }) {
  const [selectedDate, setSelectedDate] = useState<Date | null>(null);
  const [slots, setSlots] = useState<Slot[]>([]);
  const [selectedSlot, setSelectedSlot] = useState<Slot | null>(null);

  useEffect(() => {
    if (!selectedDate) return;
    fetch(`/api/specialists/${specialistId}/slots?date=${formatDate(selectedDate)}&duration=${durationMinutes}`)
      .then(r => r.json())
      .then(setSlots);
  }, [selectedDate]);

  return (
    <div className="grid grid-cols-2 gap-8">
      <CalendarPicker
        value={selectedDate}
        onChange={setSelectedDate}
        minDate={new Date()}
        maxDate={addDays(new Date(), 60)}
        disabledDates={/* вихідні та заблоковані дні */}
      />

      {selectedDate && (
        <div>
          <p className="font-semibold mb-3">{formatDate(selectedDate, 'd MMMM')}</p>
          {slots.length === 0 ? (
            <p className="text-gray-500">Немає доступних слотів</p>
          ) : (
            <div className="grid grid-cols-3 gap-2">
              {slots.map(slot => (
                <button
                  key={slot.start}
                  onClick={() => setSelectedSlot(slot)}
                  className={`py-2 text-sm rounded-lg border transition ${
                    selectedSlot?.start === slot.start
                      ? 'border-blue-600 bg-blue-50 text-blue-700'
                      : 'border-gray-200 hover:border-blue-400'
                  }`}
                >
                  {formatTime(slot.start)}
                </button>
              ))}
            </div>
          )}
          {selectedSlot && (
            <button onClick={confirmBooking} className="mt-4 btn-primary w-full">
              Записатися на {formatTime(selectedSlot.start)}
            </button>
          )}
        </div>
      )}
    </div>
  );
}

Порівняння: власне рішення vs готові сервіси

Власне рішення дає виграш у продуктивності до 2 разів при піковому навантаженні завдяки відсутності накладних витрат на зовнішні API.

Коли варто замовити індивідуальне бронювання?

Готові сервіси підходять для швидкого запуску, але якщо потрібен унікальний інтерфейс, інтеграція з 1С або повний контроль над даними — краще custom-розробка. Вона окупається завдяки відсутності щомісячних платежів та можливості масштабувати систему під зростання бізнесу. Отримайте консультацію нашого інженера — він допоможе обрати оптимальний шлях.

Процес роботи та терміни

Орієнтовний термін — від 1,5 до 3 тижнів залежно від складності інтеграцій. Зв'яжіться з нами для точної оцінки вашого проекту.

Що входить у результат

• Вихідний код на TypeScript та React
• REST API з документацією (Swagger)
• Інструкція з розгортання та підтримки
• Гарантія 30 днів на відсутність багів
• Можливість доопрацювань під бізнес-процеси

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

Розробка систем реального часу: 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).

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