Debug This Architecture

I'll analyze this architecture systematically and identify critical issues with their solutions.

Critical Failure Modes & Race Conditions

1. Server Island Problem

Issue: Users connected to different servers can't see each other's changes in real-time due to 2-second polling delay.

Race Condition:

Time 0: User A (Server 1) types "Hello"
Time 0.5: User B (Server 2) types "Hi" 
Time 2: Server 2 polls and gets "Hello", but User A never sees "Hi" until next poll

Solutions:

• Option A: Message broker (Redis Pub/Sub, RabbitMQ)
  • Trade-off: Adds complexity but enables true real-time sync
• Option B: Sticky sessions with session affinity
  • Trade-off: Simpler but reduces load balancing effectiveness
• Option C: Centralized WebSocket service
  • Trade-off: Single point of failure but eliminates server islands

2. Clock Skew & Timestamp Conflicts

Issue: Client-side timestamps are unreliable for conflict resolution.

Race Condition:

User A (clock +30s): Edit at "12:00:30" (actual 12:00:00)
User B (correct clock): Edit at "12:00:15" (actual 12:00:15)
Result: User A's older edit wins due to clock skew

Solution: Server-side Lamport timestamps or vector clocks

// Server assigns logical timestamps
const change = {
  content: edit.content,
  serverTimestamp: Date.now(),
  logicalClock: ++serverLogicalClock,
  serverId: process.env.SERVER_ID
}

3. Database Write Conflicts

Issue: Multiple servers writing simultaneously can cause data corruption.

Race Condition:

-- Server 1 and Server 2 simultaneously:
UPDATE documents SET content = 'Version A', version = version + 1 WHERE id = 123;
UPDATE documents SET content = 'Version B', version = version + 1 WHERE id = 123;
-- One update gets lost

Solution: Optimistic locking with version numbers

UPDATE documents 
SET content = $1, version = version + 1, updated_at = NOW()
WHERE id = $2 AND version = $3
RETURNING version;
-- If no rows affected, retry with conflict resolution

Scaling Bottlenecks

4. PostgreSQL Write Bottleneck

Issue: Single PostgreSQL instance becomes write bottleneck as user count grows.

Solutions:

• Option A: Operational Transform (OT) with batched writes

  // Batch operations every 100ms
  const batch = operations.splice(0, MAX_BATCH_SIZE);
  await db.query('INSERT INTO operations (doc_id, operation, timestamp) VALUES ...', batch);
  

• Option B: Event sourcing with separate write/read models
• Option C: Database sharding by document ID

5. WebSocket Connection Limits

Issue: Each server has OS-level limits (~65k connections per server).

Solution: Connection pooling and WebSocket clustering

// Use Redis adapter for Socket.io clustering
const io = require('socket.io')(server);
io.adapter(require('socket.io-redis')({ host: 'redis-cluster' }));

6. Memory Exhaustion from WebSocket State

Issue: Each connection stores document state in memory.

Solution: Stateless WebSockets with Redis for session storage

// Store connection state in Redis
await redis.hset(`session:${socketId}`, {
  userId: user.id,
  documentId: doc.id,
  lastSeen: Date.now()
});

Data Consistency Issues

7. Polling Delay Data Loss

Issue: 2-second polling can miss rapid changes or cause ordering issues.

Solution: Change Data Capture (CDC) with PostgreSQL logical replication

-- Enable logical replication
CREATE PUBLICATION doc_changes FOR TABLE documents, document_operations;
-- Consume changes in real-time instead of polling

8. JWT Token Security Vulnerabilities

Issue: 24-hour localStorage JWTs can't be revoked and are XSS vulnerable.

Solution: Short-lived access tokens + secure refresh tokens

// 15-minute access token + httpOnly refresh cookie
const accessToken = jwt.sign(payload, secret, { expiresIn: '15m' });
res.cookie('refreshToken', refreshToken, { 
  httpOnly: true, 
  secure: true, 
  sameSite: 'strict' 
});

Performance & Reliability Issues

9. CDN Caching Stale API Data

Issue: 5-minute API response caching serves stale document data.

Solution: Cache invalidation strategy

// Invalidate CDN cache on document updates
await cloudfront.createInvalidation({
  DistributionId: 'DISTRIBUTION_ID',
  InvalidationBatch: {
    Paths: [`/api/documents/${documentId}*`],
    CallerReference: Date.now().toString()
  }
});

10. Full Document Snapshot Inefficiency

Issue: Storing complete HTML every 30 seconds wastes storage and bandwidth.

Solution: Delta compression with operational transforms

// Store only operations, reconstruct document as needed
const operations = await db.query(
  'SELECT * FROM document_operations WHERE doc_id = $1 ORDER BY timestamp',
  [docId]
);
const document = applyOperations(baseDocument, operations);

Recommended Architecture Improvements

1. Event-Driven Architecture

Client → WebSocket → Message Broker → All Servers → Clients
                  ↓
              Event Store (PostgreSQL)

2. CRDT (Conflict-free Replicated Data Types)

Replace last-write-wins with proper collaborative editing algorithms:

// Use libraries like Yjs or ShareJS
import * as Y from 'yjs'
const ydoc = new Y.Doc()
const ytext = ydoc.getText('content')
// Automatic conflict resolution without data loss

3. Microservices Separation

• Document Service: CRUD operations
• Collaboration Service: Real-time sync
• User Service: Authentication/authorization
• Notification Service: User presence, cursors

This architecture addresses the major issues while maintaining scalability and reliability for a production collaborative editor.