Design a real‑time collaborative text editor that supports multiple users editing the same document simultaneously, ensuring low latency, high availability, and eventual consistency across a globally distributed user base.

CIRCLES framework + step‑by‑step strategy (120‑150 words, no story)

1. Clarify scope: real‑time sync, global users, low latency.
2. Identify stakeholders: end users, product, ops.
3. Requirements: <50 ms latency, <1 % merge conflicts, 99.99 % uptime.
4. Constraints: network variability, data consistency, storage limits.
5. List options: CRDT vs OT, sharding vs monolith, WebSocket vs long polling.
6. Evaluate trade‑offs: CRDT offers eventual consistency with simpler conflict resolution; OT provides stronger consistency but higher complexity.
7. Summarize chosen architecture: CRDT‑based document model, sharded WebSocket servers behind a load balancer, global CDN for static assets, asynchronous replication to regional databases, monitoring via Prometheus/Grafana.

I would architect a CRDT‑based collaborative editor to guarantee eventual consistency without complex operational transformation logic. The system would consist of sharded WebSocket servers behind a global load balancer, each server handling a subset of documents and users. Documents are stored in a horizontally scalable NoSQL store with per‑document sharding and replicated to regional clusters for low‑latency reads. Real‑time updates propagate via WebSocket, with each client applying CRDT operations locally and sending them to the server. The server broadcasts operations to other clients and persists them to a write‑through cache before committing to the database. Monitoring is handled by Prometheus metrics exposed by each component, with alerts for latency spikes and replication lag. Security is enforced via TLS, JWT authentication, and per‑document access controls. This design balances low latency, high availability, and eventual consistency while remaining horizontally scalable.