This architecture contains several critical flaws that would lead to data loss, inconsistent state, and poor user experience in a real-time environment.

---

1. The "Split-Brain" Broadcast Problem

Issue: The architecture only broadcasts changes to clients connected to the same server. Because connections are distributed across multiple servers, users on Server A will never see edits made by users on Server B in real-time. Solution: Implement a Pub/Sub mechanism (using Redis Pub/Sub). When a server receives an update, it publishes the change to a Redis channel. Every API server subscribes to this channel and broadcasts the update to all its connected clients.

• Trade-off: Adds latency to the broadcast loop and increases Redis memory usage.

2. Clock Skew and "Last-Write-Wins" (LWW)

Issue: Relying on client-side timestamps for conflict resolution is dangerous. Client clocks drift; a user with a "future" clock will consistently overwrite everyone else's work. Furthermore, LWW at the paragraph level results in "lost updates" (e.g., if User A adds a word and User B adds a word to the same paragraph, one user's edit is deleted entirely). Solution: Move to Operational Transformation (OT) or Conflict-free Replicated Data Types (CRDTs). Use a logical clock (Lamport timestamp) or a central sequencer at the server level to order operations.

• Trade-off: CRDTs/OT are significantly more complex to implement than LWW.

3. Database Bottleneck & Race Conditions

Issue: Polling PostgreSQL every 2 seconds is inefficient and creates a "thundering herd" problem as the user base grows. Additionally, the standard "write to DB" flow on every keystroke will kill PostgreSQL performance under load. Solution:

1. Write Buffering: Use Redis to buffer document changes in memory. Flush updates to PostgreSQL asynchronously (e.g., every 5 seconds or when the document is closed).
2. Change Data Capture (CDC): Replace polling with a tool like Debezium to stream database changes to the application servers.

• Trade-off: Increases risk of data loss if the server crashes before the buffer is flushed (mitigate with a write-ahead log/AOF in Redis).

4. CDN Caching of API Responses

Issue: Caching API responses for 5 minutes via CloudFront is catastrophic for a collaborative editor. Users will see "stale" document states for up to 5 minutes, effectively breaking real-time collaboration. Solution: Disable CDN caching for WebSocket-related API endpoints or any document-fetching route. Use Cache-Control headers (no-store, no-cache) for dynamic document data.

• Trade-off: Puts higher load on the backend servers since they must serve every request.

5. Security & Auth Vulnerabilities

Issue: Storing JWTs in localStorage makes the application vulnerable to Cross-Site Scripting (XSS) attacks, where a malicious script can steal the token. 24-hour expiry without a refresh mechanism forces a hard logout, disrupting work. Solution: Store JWTs in HttpOnly, Secure, SameSite=Strict cookies. Implement a Refresh Token rotation strategy.

• Trade-off: Requires protection against Cross-Site Request Forgery (CSRF).

6. Storage Strategy (Snapshots)

Issue: Saving full HTML snapshots every 30 seconds is inefficient for long documents and creates a "gap" where the last 29 seconds of work could be lost if the server crashes. Solution: Store the Operation Log (the sequence of edits) as the source of truth. Take snapshots only as an optimization to speed up document loading (e.g., once every 100 edits).

• Trade-off: Replaying a long log of operations can be slow; requires periodic "compaction" of the log.

7. Load Balancer & WebSocket Affinity

Issue: Round-robin load balancing is fine for REST, but WebSockets are long-lived. If the load balancer kills a connection during a rolling deployment, the user loses their collaborative state. Solution: Implement "Graceful Shutdown" in the Node.js servers, allowing existing WebSocket connections to drain before the server process exits. Use sticky sessions if the architecture requires it, though a well-implemented Pub/Sub model makes this less critical.

• Trade-off: Increases complexity of deployment pipelines.

---

Summary of Recommended Architecture Changes

Feature	Current State	Proposed State
Sync	LWW (Client Timestamps)	CRDTs / OT (Logical Sequencing)
Broadcast	Local Server Only	Redis Pub/Sub
DB Sync	Polling every 2s	Asynchronous buffering + CDC
Caching	5-min CDN Cache	No caching for dynamic data
Auth	LocalStorage	HttpOnly Cookies + Refresh Tokens