Перейти к содержанию
В рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVI
SmartyDevs
Инженерия · 07

Real-time, который выживает переподключение.

Совместные редакторы, живые дашборды, presence, чат, уведомления и event streams — спроектированы с серьёзным отношением к реальности сети, переподключений и conflict resolution.

§ 01The problem

Какую проблему решаем

Real-time выглядит легко в демо и становится сложным в момент, когда два пользователя редактируют один документ на нестабильном Wi-Fi. Переподключения, упорядочивание, presence, разрешение конфликтов, fan-out, backpressure — то, что ломается под реальной нагрузкой. Мы запускали коллаборацию и live-системы в масштабе и знаем, что ломается первым.

§ 02Capabilities

Что собираем

  • 01WebSocket и Server-Sent Events бэкенды с переподключением
  • 02Presence, курсоры, live selection и awareness-примитивы
  • 03Совместное редактирование с CRDT (Yjs, Automerge)
  • 04Operational transform там, где CRDT не подходят
  • 05Живые дашборды на стримах, а не на поллинге
  • 06Чат и сообщения с подтверждением доставки, прочтения и индикатором печати
  • 07Push-нотификация fan-out в масштабе
  • 08Event streaming на Kafka или Redpanda
  • 09Backpressure, rate limiting и graceful degradation
  • 10Наблюдаемость, настроенная под долгоживущие соединения
§ 03Deliverables

Что получаете

  • Real-time бэкенд с задокументированными инвариантами
  • Клиентские библиотеки с корректным переподключением и офлайном
  • Отчёт по нагрузочному тестированию на реалистичных сценариях concurrent-пользователей
  • Runbook на failure modes, специфичные для real-time
§ 04Stack

Стек, к которому тянемся

Node.js · Go
Postgres · Redis
Yjs · Automerge
Liveblocks
PartyKit
Cloudflare Durable Objects
Kafka · Redpanda
OpenTelemetry
§ 05Ideal for

Подходит

  • Коллаборативным инструментам (документы, дизайн, project management)
  • Живым дашбордам и operational-tooling
  • Trading и финансовым интерфейсам, требующим свежих данных
  • Мультиплеер-фичам в SaaS-продуктах
§ 06Process

Как идёт проект

  1. 01

    Архитектура

    Модель соединения, модель состояния, fan-out и persistence — выбраны под ваш масштаб. Trade-off'ы записаны.

  2. 02

    Фундамент

    Надёжный транспорт, переподключение, presence и наблюдаемость — скучный слой, на котором стоит всё остальное.

  3. 03

    Поставка фич

    Коллаборация, чат, нотификации или другая real-time поверхность — построена на фундаменте.

  4. 04

    Нагрузочное тестирование и запуск

    Протестировано под реальной concurrent-нагрузкой до того, как пользователи увидят. Failure modes задокументированы.

§ 07Engagement

Как сотрудничать

01

Прототип

2 — 4 недели

Доказательство архитектуры на вашем конкретном сценарии до коммита на полную разработку.

02

Real-time Build

8 — 14 недель

Production real-time фича сдана end-to-end с документацией и нагрузочными тестами.

§ 08Common questions

Frequently asked.

01Нужна ли своя инфраструктура или можно использовать SaaS?

И то, и другое — валидно. Liveblocks, PartyKit и Cloudflare Durable Objects покрывают много кейсов с меньшей операционной нагрузкой. Self-hosted имеет смысл в специфичном масштабе, по причинам комплаенса или стоимости — скажем, что подходит вам.

02Как работаете с офлайном?

Зависит от фичи. Для коллаборации используем CRDT, которые корректно мерджат офлайн-правки; для чата — очередь и replay; для дашбордов — делаем staleness видимым пользователю.

Есть задача, которую стоит решить как следует?

Напишите, какой результат нужен. Мы честно скажем, во что это обойдётся — письменно, в течение недели.

Начать разговор