Design an Asynchronous Video Moderation Pipeline with ML Risk Scores and a Rules Engine

Design a simplified video content moderation system. Video upload is out of scope: assume an existing system delivers each newly published, already-uploaded video to you. Your job is to design the moderation pipeline itself, which has four stages: 1. **Video ingestion.** A user publishing a video starts the moderation process. Results do not need to be real time. The user is first told the video is "under review" and is later notified whether it was approved or taken down. 2. **Model scoring.** The pipeline calls many ML models, for example 20 to 30. Each returns a risk score between 0 and 1, where a higher score means higher risk. Different models evaluate different aspects of the video, such as text models and visual models, and they take different inputs and parameters. 3. **Rules and policy engine.** Business rules are configured over the model scores. For example, "model A > 0.9 AND model B > 0.95" means the video violates policy. Real rules are much more complex than this example. 4. **Enforcement actions.** When a rule matches, the pipeline calls downstream APIs, such as a video service and an account service, to take the video down, ban the account, or take similar actions. ### Clarifying Questions - What upload volume should the pipeline be sized for, and how long can an end-to-end review take? - Can a video be reviewed again later, for example after a rule or model changes or after an appeal? - When several rules match with different actions, how is the final action chosen? - Where should moderation results flow back to: the uploader's notification, downstream services, human review, or model training data? ### Part 1 — Pipeline Architecture Draw the end-to-end flow, covering all four stages, from the moment a video is handed to the pipeline to the final notification. ```hint Let the slowest stage set the shape Model calls differ in their inputs and cost. Think about how the pipeline waits for many independent scores before it can evaluate a rule. ``` #### What This Part Should Cover - How a review is triggered and how its state is tracked from "under review" to a final outcome. - Sending the video to many different models and collecting their scores. - Rule evaluation, dispatching actions to downstream services, and notifying the user. ### Part 2 — Data Model with Versioning and Audit Design the data model. Both models and rules must be versioned, and an audit table must record the basis for every decision. ```hint Make every decision reproducible Ask what you would need to store to explain, months later, exactly why a particular video was taken down. ``` #### What This Part Should Cover - Entities for reviews, model versions, rule versions, scores, decisions, and actions. - How each decision points to the exact model versions, rule versions, and scores it used. - Why audit records must never be changed after they are written. ### Part 3 — Rule Engine Configuration and Result Feedback How are rules configured? How do moderation results flow back into the rest of the system? ```hint Separate rule authoring from rule execution Consider how a policy author changes a rule safely and how the running pipeline picks up that change without a redeploy. ``` #### What This Part Should Cover - A rule format expressive enough for combinations of scores, and how rules are validated and deployed. - Safe rollout of rule changes, and how rules and models stay compatible across versions. - The paths by which results reach users, downstream services, and any feedback loop. ### Part 4 — Scaling and Failure Handling Leave time for this part. How does the pipeline scale? What happens when a model, the rule engine, or a downstream API fails? ```hint Follow one video through a failure Trace what happens to a video when its third model call times out. Make sure the video neither gets stuck nor gets reviewed twice with conflicting outcomes. ``` #### What This Part Should Cover - Scaling model calls when models differ in cost and capacity. - Retries, timeouts, idempotency, and dead-letter handling across stages. - Safe behavior for enforcement actions when downstream calls fail. ### What a Strong Answer Covers - A block diagram of the four stages drawn early, before detailed table schemas, so the discussion reaches scaling and failure handling. - Asynchronous processing with tracked state that matches the "under review, notify later" requirement. - Versioned models and rules, with an audit trail that can reproduce any decision. - A configurable rule engine with safe rollout. - Idempotent enforcement, and monitoring of the pipeline's backlog, latency, and error rates. ### Follow-up Questions 1. How would you test a new rule against past videos before enabling it? 2. If an outage means one model returns scores for only some videos, should the pipeline treat missing scores as safe, treat them as violations, or do something else? 3. How would you let a human reviewer override an automated decision while keeping the audit trail consistent?