Content Management Platform

Topology Notes

• ·Redis holds published content objects keyed by content:{locale}:{content_id}. TTL is 1 hour for standard content and 5 minutes for "live" content types (breaking news, real-time scores). On publish, the content service writes the new content value into Redis atomically with the PostgreSQL publish transaction commit using the outbox pattern: do not delete the key and rely on miss repopulation. Draft content is never written to the Redis published content namespace.
• ·Content preview for editors uses a separate URL path (/preview/{draft_id}) that explicitly bypasses all Redis caches and reads directly from PostgreSQL primary. The preview response must include a no-cache header to prevent the browser from caching the draft. The preview service authenticates against the editorial session, not the public reader session: public readers cannot construct valid preview URLs.
• ·PostgreSQL primary handles all editorial writes (draft creation, workflow state transitions, publish events). The read replica handles all public reader content fetches and analytics queries. The routing decision is made at the connection pool layer (read replica for SELECT on published content, primary for all editorial mutations and freshness-critical reads). Replication lag is monitored; if lag exceeds 10 seconds, reader traffic is rerouted to the primary until lag recovers.
• ·Elasticsearch receives content index events from an outbox relay that reads committed publish and update events from PostgreSQL. The indexer constructs the full content document (including author, category, and tag denormalization) and issues a bulk index API call. The index refresh_interval is set to 5 seconds for the content index to balance search freshness with indexing overhead. A separate alias points to the current live index; re-indexes are performed on a shadow index and alias-swapped atomically.
• ·Content relationship queries (fetch article with author + categories + related articles) use a single PostgreSQL query with JOINs or a two-query pattern (article + batch IN clause for all related entity IDs). The application layer assembles the response object from the multi-table result set. No per-article relationship query is issued within a list response. This is enforced by query pattern tests in the integration test suite.