Architecture Note: Real-Time Comment Service for Trello

The Problem: Low-Latency Collaborative Updates

In a collaborative environment like Trello, users expect card comments to appear instantly across all open clients without manual refreshing. The primary challenge is balancing immediate propagation (low latency) with strict data persistence and access control, ensuring that a user on a different continent sees a comment within 200ms of it being posted.

Minimal Suitable Design

The smallest viable architecture consists of a dedicated Comment Service (Node.js/Express) managing CRUD operations, a relational database for persistence, and a pub/sub mechanism for real-time delivery.

• Persistence: A PostgreSQL table stores the source of truth: comments(card_id BIGINT, user_id BIGINT, content TEXT, ts TIMESTAMP).
• Propagation: When a comment is saved, the service publishes a message to a Redis Pub/Sub channel named card:{card_id}:comments.
• Delivery: A WebSocket gateway maintains active connections with clients. It subscribes to the relevant Redis channels based on the cards the user is currently viewing and pushes the JSON payload to the browser.

Example Configuration

The following environment variables define the connectivity for the Comment Service instance:

# Comment Service Environment Variables
REDIS_URL=redis://redis-cluster:6379/0
PG_HOST=pg-primary.internal
PG_DB=trello
PG_USER=comment_service
PG_PASSWORD=********
WS_GATEWAY_URL=wss://ws.trello.com/comments

Trust and Data Boundaries

To prevent unauthorized access or data leaks, the service implements three layers of boundary control:

1. Authentication: The service does not manage sessions; it validates JWTs (JSON Web Tokens) issued by Trello's central auth service to identify the user_id.
2. Authorization: Before any read or write, the service verifies that the card_id belongs to a board the user is permitted to access via a lightweight Access Control List (ACL) cache.
3. Data Protection: To protect PII (Personally Identifiable Information), comment content is encrypted at rest using PostgreSQL's pgcrypto module. Data is stored via pgp_sym_encrypt(content, key), with keys managed in an external Vault instance.

Operational Checks

System health is monitored through specific probes and middleware to ensure stability under load.

• Health Probes: GET /healthz verifies that the service can successfully ping both the PostgreSQL instance and the Redis cluster.
• Rate Limiting: A token-bucket middleware limits users to 30 comments per minute per user_id to prevent API abuse, returning an HTTP 429 (Too Many Requests) when exceeded.
• Content Filtering: A moderation middleware scans the content string for profanity or spam patterns before the record is committed to the database.

Diagnostic Check

Run this command from a monitoring host to verify the service's internal health status:

# Execute as a monitoring user
curl -s -o /dev/null -w "%{http_code}" https://api.trello.com/internal/comments/healthz
# Expected Output: 200

Failure Modes and Recovery

The architecture accounts for three primary failure scenarios to avoid total service blackout:

Conditions for Redesign

This design is optimized for current loads but would require modification under the following conditions:

• Scale: If volume exceeds 1M comments/day, the comments table must be sharded by card_id or moved to a time-series database.
• Compliance: If regulatory requirements demand an immutable audit trail, the system would move to an append-only log where UPDATE and DELETE operations are forbidden via DB triggers.
• Offline Capability: Supporting offline mobile edits would require a local SQLite cache on the client and a conflict-resolution strategy (e.g., vector clocks) to handle concurrent edits.
• Media: If comments support large attachments, the content field would store a URI pointing to an object storage service (S3) rather than the binary data.