Katkat
Back

Design a stock order manager

DatabricksSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design an equity Order Management System (OMS) that manages order lifecycles, ensures idempotent broker interactions, and guarantees state reconciliation under distributed failures.

Scenario

You are tasked with designing an Order Management System (OMS) for a retail trading platform. The OMS sits between customer-facing trading APIs and an external third-party clearing brokerage. It is responsible for accepting user trade requests, maintaining order lifecycles, routing executions to the broker, and processing asynchronous fill updates while guaranteeing that no orders are duplicated, lost, or left in an inconsistent state.

Requirements

Functional Requirements

  • Order Placement & Cancellation: Support placing market and limit buy/sell orders, as well as cancelling pending orders.
  • Order Lifecycle Management: Model and enforce valid state transitions (e.g., PENDING_NEW, SUBMITTED, PARTIALLY_FILLED, FILLED, CANCELLED, REJECTED).
  • Broker Integration: Send orders reliably to external broker APIs, handle synchronous communication failures, and ingest execution reports (fill notifications).
  • State Reconciliation: Detect and resolve discrepancies between the internal OMS state and the broker's actual state (e.g., missed webhooks, network partitions, out-of-order events).
  • Audit & History: Maintain an immutable record of all state transitions and execution events for regulatory audit.

Non-Functional Requirements

  • Strict Idempotency: Guarantee that duplicate client requests or retries never result in duplicate executions at the broker.
  • Consistency: Strong consistency on individual order states and fill balances. Prevent race conditions such as filling an order after a cancellation has been confirmed.
  • Availability & Durability: Zero data loss. Orders must survive process crashes and broker connectivity drops.
  • Low Latency: Order ingestion acknowledgment p99 latency under 50ms.

Scale & Numbers

  • Daily Volume: 10 million orders created per day.
  • Peak Traffic: 2,500 order submissions/sec at market open; 5,000 broker fill/status events/sec.
  • Read Traffic: 15,000 status checks/sec.
  • Storage Retention: Active orders live in hot storage for 7 days; cold audit history retained for 7 years.

What Your Design Should Cover

  1. Core Data Model & State Machine: The order data model, event log, and explicit state transition graph.
  2. Architecture & Component Diagram: Ingestion service, transactional outbox / message broker, broker gateway adapter, and reconciliation workers.
  3. Idempotency & Failure Handling: How client-provided idempotency keys are tracked, and how timeouts during broker calls are resolved.
  4. Asynchronous Reconciliation: Strategy for reconciling missed or out-of-order broker webhooks (polling, audit log diffing, dual writes).

Hints

Hint 1

Use a transactional outbox pattern or distributed event log to decouple client order acknowledgment from synchronous network calls to the external broker.

Hint 2

Model order transitions as an append-only event log driven by an explicit finite state machine (FSM) to naturally handle out-of-order execution reports.

Hint 3

Pair real-time push events from the broker with a scheduled polling reconciler that compares terminal states and execution totals against broker reports.

Follow-up questions

  • How does your system handle a network timeout when submitting an order to the broker, where it is unknown if the broker received the request?
  • If a user submits a cancellation request at the exact moment the broker executes a full fill, how does your system resolve the race condition?
  • How would you shard the database to support 2,500 writes/second while maintaining strict consistency and isolation per account?