Design a Scheduled Social Media Post Service
We want to build a service that allows content creators to schedule social media posts to be published at a specific date and time in the future. The system accepts post content and target timestamps, then triggers execution to social platforms when the scheduled time arrives. You need to design the scheduling storage and execution system.
This brief is incomplete on purpose, as it would be in a real interview. Ask the interviewer about the users, the features, the targets and the traffic. Whatever you uncover is added below.
- Creators can create, view, update, or cancel scheduled posts up to 30 days in advance.
- The system must trigger publication of scheduled posts within 1 minute of their target time.
- Each scheduled post must be published exactly once to destination platforms.
- Execution history
- Scheduler scalability
- API availability
- Third-party rate limits
- Active creators
- Post payload size
- Peak scheduling bursts
- The API endpoints for creating, updating, and cancelling scheduled posts
- The data model for storing pending jobs, post states, and execution status
- The architecture diagram showing the scheduler engine, task queues, and worker pool
- The execution sequence showing how due jobs are fetched, locked, and executed exactly once
Designs an efficient delayed execution engine (such as time-partitioned indices, Redis Sorted Sets, or dedicated delay queues) that avoids costly full table scans over pending jobs.
Defines explicit job states (e.g., SCHEDULED, PROCESSING, PUBLISHED, FAILED) and uses atomic conditional updates or distributed locks to guarantee exactly-once processing.
Buffers top-of-the-hour posting spikes using message queues and decouples time-based trigger fetching from actual HTTP publishing workers.
Handles worker crashes, deadlocks, and target API rate limits using visibility timeouts, exponential backoff retries, and dead-letter queues.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Focus on the scheduling storage, delayed job lookup, state management, and worker dispatch pipeline. Do not design social media OAuth authorization flows or media transcoding pipelines.
- Views
- 2