Design a Configurable Order Validator with DAG Dependencies

Quick Overview

Design an `OrderValidator` whose rules check prohibited items, price ranges, and future conditions. Make the API or object boundaries explicit, then cover invariants, edge cases, testing strategy, and operational trade-offs.

Design a Configurable Order Validator with DAG Dependencies

Company: Bytedance

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: hard

Interview Round: Technical Screen

# Design a Configurable Order Validator with DAG Dependencies Design an `OrderValidator` whose rules check prohibited items, price ranges, and future conditions. Rules can be added or removed without code changes and may depend on other rules in a DAG. Removing a rule connects each predecessor to each successor while preserving an acyclic valid evaluation graph. ### Constraints & Assumptions - Rule definitions are stored as validated data, such as JSON. - Evaluation must report failures and configuration errors separately. ### Clarifying Questions to Ask - Do all prerequisites need to pass before a rule runs? - What happens if rewiring creates a cycle? ### What a Strong Answer Covers - Schema, safe operators, DAG validation, topological execution, and versioning. - Atomic add/remove operations and testability. ### Follow-up Questions - How would rule rollouts be audited? - How would expensive independent rules run concurrently?

Quick Answer: Design an `OrderValidator` whose rules check prohibited items, price ranges, and future conditions. Make the API or object boundaries explicit, then cover invariants, edge cases, testing strategy, and operational trade-offs.

|Home/Software Engineering Fundamentals/Bytedance
Bytedance logo
Bytedance
Jul 31, 2026, 12:00 AM
hardSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
0
0

Design a Configurable Order Validator with DAG Dependencies

Design an OrderValidator whose rules check prohibited items, price ranges, and future conditions. Rules can be added or removed without code changes and may depend on other rules in a DAG. Removing a rule connects each predecessor to each successor while preserving an acyclic valid evaluation graph.

Constraints & Assumptions

  • Rule definitions are stored as validated data, such as JSON.
  • Evaluation must report failures and configuration errors separately.

Clarifying Questions to Ask Guidance

  • Do all prerequisites need to pass before a rule runs?
  • What happens if rewiring creates a cycle?

What a Strong Answer Covers Guidance

  • Schema, safe operators, DAG validation, topological execution, and versioning.
  • Atomic add/remove operations and testability.

Follow-up Questions Guidance

  • How would rule rollouts be audited?
  • How would expensive independent rules run concurrently?
Loading comments...