Loading...
real time collarboration
version control
access control
user authentication
document sharing through link/email
comments and annotation
rich text edition
offline access
notification
reliability, TP 99.9
scalability
consistency
reall time updates under 100ms
DAU: 300K
doc size: 100KB
doc per user per day: 2
actions: 10 edit, 2 comment, 1 save, 1 version control per doc per user = 19 actions
qps:
average:
19 * 2 * 300K / 24 / 3600 = 131 qps
peak:
131 * 2 = 262 QPS
network bandwidth:
131 * 10K = 1M
peak: 2M
data storage:
100K * 2 * 300K = 60,000M = 60G every day
storage 3 years, 3 replica = 197K G = 197TB
actions : 19 * 10K * 300K * 3 * 3 = 513KK = 513M
/post?user_id, content
/edit?user_id, content
PATCH /documents/{docId}
Content-Type: application/json
{
"userId": "12345",
"operations": [
{"op": "insert", "position": 10, "text": "Hello World!"},
{"op": "delete", "position": 15, "length": 5}
]
}
GET /documents/{docId}?version=latest
POST /documents/{docId}/permissions
Content-Type: application/json
{
"userId": "6789",
"role": "commenter"
}
/comment?user_id, content
/auth?user_id, password, post_id
/share?user_id
doc:
doc_id
user_id
content varchar
permissions:
doc_id
user_id
permission_level
user:
user_id
user_infos
comment:
comment_id
comment_content
doc_id
notification_preference
user_id
preference_infos
backend server
Operational Transformation (OT) / Conflict-Free Replicated Data Types (CRDTs): Used for real-time collaborative editing.
cassandra/hbase:Distributed Storage: Documents are stored in a scalable, highly available system.
cache
sql db
kafka for notification
notification server for websocket connections
User Loads Document → Request goes to a Load Balancer, fetching document metadata and content.
User Makes Edits → Updates are sent to a Collaboration Server.
Collaboration Engine Processes Edits → Conflicts are resolved using Operational Transformation (OT) or CRDTs.
Changes Propagated to Other Users → Updates are pushed in real-time via WebSockets.
Auto-Save & Versioning → Changes are periodically stored in Google Cloud Storage.
Syncing for Offline Users → Local changes are queued and merged once online.
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
document metadata: use spanner, distributed sql db to store document and ownership
document content: use bigtable/hbase
version history: google storage/ S3
collaboration:
real-time editing: user websockets & OT algorithm
conflict handling: OT/CRDTs
undo & version: immutable snapshots & delta logs
latency reduction: edge caching with CDN
real time communication:
use kafka event stream , websocket
offline mode: use local storage to keep edits offline
delta logs to store incremental updates
Explain any trade offs you have made and why you made certain tech choices...
read optimized db sharding:
horizontal partitioning: distribute read across multiple database nodes. and apply geographical replication. trade off: offloads read pressure but introduce replication lag.
write scalability:
user edits stored as delta changes
changes are batched and applied periodically
websockets push incremental updates
trade off low latency for conflict resolution.
write coalescing & eventual consistency
reduce network congestion but introduce delay
server crash:
use distributed load balancing, active/active mode
network failure: change to offline mode and add sync queue
sclaing issues: multi region deployments & sharded storage
data loss: versioning & backups
Hot Document:
ensure consistency
use mutli level caching, edge CDN caching, redis and local browser cache
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
add ai assist writing