# Design a Pre-Trade Risk Check for an Electronic Order Path Design a pre-trade risk-checking service for an electronic trading path. A strategy submits a new order to an order manager, an approved order proceeds to an exchange gateway, and acknowledgements, fills, and cancellations return from the exchange. Every outbound order must be checked before it leaves the controlled system; any order that breaches a configured limit must be rejected and must never reach the exchange gateway. ### Constraints & Assumptions - Optimize for correctness first, while keeping added latency predictable. - Limits may depend on an account, strategy, instrument, and current exposure. - Multiple order managers may submit concurrently. - Exchange events may be delayed, duplicated, reordered, or temporarily unavailable. - The design must be testable, observable, and operable during configuration changes and partial failures. ### Clarifying Questions to Ask - Which limits are hard blockers, and which produce warnings? - Does open-order exposure count immediately on approval or only after exchange acknowledgement? - What consistency and availability trade-off is acceptable when risk state is unavailable? - Who may change limits, and how quickly must changes take effect? ### Part 1: Components and Interfaces Sketch the order path, risk decision interface, state owners, configuration flow, and audit trail. #### What This Part Should Cover - A fail-closed enforcement point that cannot be bypassed by normal order flow. - An idempotent decision contract tied to a stable order identifier and limit version. - Explicit ownership of reservations, fills, cancels, and exposure state. ### Part 2: Correctness Under Concurrency and Failure Explain how the system prevents two individually acceptable concurrent orders from jointly exceeding a limit, and how it recovers from uncertain downstream outcomes. #### What This Part Should Cover - Atomic check-and-reserve semantics at the relevant risk scope. - Idempotency and reconciliation for duplicated or reordered events. - Conservative behavior during partitions, stale configuration, and gateway ambiguity. ### Part 3: Performance, Testing, and Operations Describe the hot path, scaling strategy, tests, metrics, and safe rollout procedures. #### What This Part Should Cover - Partitioning and local state only where ownership remains unambiguous. - Latency budgets, load shedding, backpressure, and degraded-mode policy. - Deterministic simulations, invariant tests, fault injection, replay, and shadow evaluation. - Decision, rejection, staleness, reconciliation, and saturation metrics. ### What a Strong Answer Covers - A non-bypassable, fail-closed gate with atomic exposure reservation. - A state machine spanning submit, approve, reject, acknowledge, fill, cancel, timeout, and reconcile. - Versioned limit configuration, complete auditability, and controlled rollback. - Honest trade-offs among consistency, latency, availability, partitioning, and operational simplicity. ### Follow-up Questions - How would you support a global limit that spans multiple partitions? - How would you deploy a new risk rule without unexpectedly blocking all traffic? - How would you prove that no accepted order escaped risk checking during an incident?