Completed architectural and performance analysis of the transition from long-polling/SSE to short-polling with post meta storage for collaborative editing sync.

Findings

Critical Performance Issues

• No message cleanup: Messages accumulate indefinitely in wp_postmeta without expiration. Active editing sessions will create thousands of rows with no garbage collection.

• Aggressive polling interval: 200ms polling (5 req/sec per client) causes excessive database load. 10 concurrent editors = 50 queries/sec continuously.

• Inefficient message retrieval: get_new_messages() fetches all messages via get_post_meta() then filters in PHP. Does not leverage database-level filtering.

• Singleton post bottleneck: All rooms share one post for storage, creating cache invalidation churn and database lock contention on every write.

• No error backoff: Failed polling requests retry at full speed (200ms) with no exponential backoff.

Architecture Concerns

• Storage model mismatch: Using add_post_meta(..., false) creates separate rows per message. Linear row growth without bounds.

• Race conditions: Non-atomic message ID generation during concurrent writes.

• Client-side issues: No Page Visibility API support, thundering herd on initial page load, continuous battery drain.

Recommended Fixes (Priority Order)

1. Implement TTL-based message cleanup or prune based on oldest active client
2. Increase polling interval to ≥1000ms with adaptive backoff when idle
3. Add exponential backoff on errors
4. Move to database-level message filtering or custom tables
5. Implement jitter and Page Visibility API support

Positive Aspects

• Eliminates SSE/long-polling proxy compatibility requirements
• Simplified HTTP-only transport
• Well-defined message validation schema
• Proper capability-based permission checks

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.