Context
Frontend Architecture Overview
Кейс про collaborative editor показывает пределы frontend-архитектуры в real-time мультиплеерных сценариях.
Design Google Docs collaborative editor требует точной синхронизации между клиентами, предсказуемого UX при задержках сети и корректного разрешения конфликтов без потери пользовательских правок.
Problem & Context
Functional requirements
- Совместное редактирование одного документа несколькими пользователями в реальном времени.
- Показ курсоров/выделений других участников и индикаторов присутствия.
- Undo/redo на клиенте без разрушения глобальной консистентности документа.
- Offline edit с последующей синхронизацией изменений после восстановления сети.
Non-functional requirements
- Задержка применения удаленного изменения в UI: желательно < 200ms.
- Высокая устойчивость к временным network partition и reconnect storm.
- Сохранность истории операций и защита от потери пользовательского ввода.
- Масштабируемость по активным документам и числу участников в одном документе.
Scale assumptions
Active documents
5M+/day
Большинство документов малые по размеру, но есть heavy collaborative sessions.
Concurrent editors per doc
1-50 typical, 200 peak
Архитектура должна корректно работать и в асимметричных сессиях с большим числом участников.
Ops throughput
10k-50k ops/s global
Пиковые окна обычно связаны с учебными/рабочими часовыми поясами.
Reconnect burst
x3 baseline
После локального сетевого сбоя часть клиентов пытается отправить буферизованные операции одновременно.
Related
Consistency & Idempotency
Collaborative editing напрямую зависит от корректной модели консистентности и обработки повторов операций.
Architecture
Realtime gateway
WebSocket/WebTransport слой для bidirectional доставки операций и presence-событий.
Collaboration engine
Применяет OT/CRDT правила, валидирует версию документа, сериализует операции и рассылает подписчикам.
Document state store
Хранит snapshot + operation log; поддерживает recovery, replay и point-in-time reconstruction.
Client sync module
Локальный буфер неподтвержденных операций, ack tracking и reconciliation после reconnect.
Deep dives
OT vs CRDT
OT обычно проще интегрировать в централизованный серверный pipeline; CRDT лучше для peer/offline сценариев, но увеличивает metadata overhead.
Ordering and causality
Сервер должен deterministically сериализовать конкурентные операции. Клиент применяет трансформации и версии, чтобы исключить divergence.
Offline-first sync
Локальные операции применяются оптимистично, затем отправляются батчами. При конфликте - rebasing и повторная валидация состояния документа.
Presence channel separation
Presence-ивенты (cursor/mouse/typing) отделяются от документных операций: можно агрессивно дропать без потери данных документа.
Trade-offs
Сильная server-side координация упрощает консистентность, но повышает зависимость от центрального collab engine.
Полный operation log удобен для аудита и отладки, но может дорого стоить по storage и replay latency.
Более частые snapshots ускоряют recovery, но увеличивают write overhead на storage.
Агрессивная компрессия операций экономит bandwidth, но усложняет дебаг и диагностику инцидентов.
Связанные главы
Clock Synchronization
Понимание временных допущений полезно для ordering и отладки конфликтов в collaborative editing.
Консистентность и идемпотентность
Ключевая база для корректной обработки повторной доставки и replay операций.
Event-Driven Architecture
Коллаборативный редактор использует event-driven поток операций и async обработку состояния.
Service Discovery
Realtime gateway и collaboration engine требуют устойчивого discovery и маршрутизации.
Design Instagram Feed
Контраст двух frontend-кейсов: read-heavy feed vs write-heavy collaborative editor.