Design a system to automate the content lifecycle

WHAT THIS TESTS: The interviewer wants to see if you can translate business policies like mandatory annual review and content decay detection into a reliable distributed system. They care about how you handle scale, failure, and time. Specifically they are looking for your ability to distinguish between polling and event-driven triggers, manage state across services, and reason about observability when jobs fail silently.

A GOOD ANSWER COVERS: First, a scheduling mechanism. Options include a workflow engine like Temporal or Cadence for durable execution, or a simpler cron job paired with a task queue and dead letter queue for retries. Second, data modeling. Content needs a published_at timestamp and a last_reviewed_at field; the scheduler queries for records where published_at is older than one year and status is not already under review. Third, analytics integration. Instead of calling the analytics API synchronously for every article, use a batch ETL or streaming pipeline to enrich content records with traffic metrics, then flag decay based on threshold rules. Fourth, idempotency and safety. Jobs must be idempotent because retries are inevitable; use database-level constraints or distributed locks to prevent duplicate review flags. Fifth, observability. Emit metrics for job lag, failure rate, and queue depth; log correlation IDs across the scheduler and worker.

COMMON WRONG ANSWERS: A red flag is suggesting a single server cron job with no retry logic or failure handling. Another is polling the entire content table every minute, which crushes the database at scale. Some candidates propose calling the analytics API inline during the flagging job without caching or batching, ignoring rate limits and latency. Proposing a purely event-driven system without a reconciliation loop is also weak, because missed events leave stale content forever.

LIKELY FOLLOW-UPS: How would you handle millions of articles without overwhelming the database? The answer is cursor-based pagination or sharded time-range queries. What happens if the analytics API is down? Decouple with a queue and apply backpressure, or use stale data with a TTL. How do you ensure an article is not flagged twice? Use a deterministic job ID or state machine transition checks. Would you use a push or pull model for the one-year review? Discuss tradeoffs: push via delayed queue messages is precise but hard to track; pull via scheduled scan is easier to audit but requires indexing.

ONE CONCRETE EXAMPLE: Imagine a CMS with two million articles. A nightly scheduled worker runs in 10-minute shards, querying articles where published_at is between 365 and 366 days ago and review_flag is false. It enqueues IDs into a Redis-backed queue. Worker nodes pick batches, idempotently set review_flag to true and notify editors via Slack. Separately, a weekly Apache Airflow DAG pulls the last 30 days of page views from the analytics API, joins on content_id, and updates a decay_score. Articles with decay_score below 100 and older than 90 days are auto-archived after human approval.