Practice/Amazon/Design a Stock Trading Service

Design a Stock Trading Service

System DesignMust

Problem Statement

Design a high-availability, low-latency stock trading service that allows users to buy and sell stocks, view live prices, manage portfolios, and access historical price data. The platform blends real-time streaming (market data and order status) with strongly consistent money and asset movements, and must stay available and fast even during market spikes.

Interviewers ask this because it forces you to reconcile low-latency fan-out with correctness under contention, multi-step workflows (order placement through settlement), and high availability. They want to see your ability to separate read and write paths, choose appropriate consistency guarantees, design real-time updates, and manage backpressure and hotspots.

Key Requirements

Functional

• Order placement -- users place buy and sell orders for specific stocks and quantities with market or limit order types
• Live market data -- users view live stock prices and receive real-time order status updates without polling
• Portfolio management -- users view and manage their portfolio including positions, balances, and pending transactions
• Historical data -- users browse and query historical price data (candles, OHLC, volume) over configurable time ranges

Non-Functional

• Scalability -- support millions of users with hot symbols (AAPL, TSLA) generating disproportionate traffic during market hours
• Reliability -- maintain 99.99% uptime during market hours; zero tolerance for double-spend or lost orders
• Latency -- order submission confirmation under 100ms, live price updates within 500ms, portfolio queries under 200ms
• Consistency -- strong consistency for order placement, balance checks, and portfolio mutations; eventual consistency for historical charts and aggregate views

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Order Placement and Balance Management

Placing an order must atomically validate the user has sufficient funds or holdings, reserve the amount, and submit the order, preventing double-spend under concurrent requests.

Hints to consider:

• Use conditional writes with optimistic locking on the user's balance record to prevent race conditions between concurrent orders
• Implement idempotency keys on every order submission so retries from flaky mobile connections do not create duplicate orders
• Separate the order lifecycle into phases: validation, reservation, submission, execution, settlement, each with compensating actions
• Design the reservation as a saga where funds are held (not deducted) until execution confirmation, with automatic release on cancellation or timeout

2. Real-Time Market Data Fan-Out

Live quotes must reach clients in near real time despite massive fan-out to millions of concurrent users watching the same symbols.

Hints to consider:

• Use a dedicated push channel (WebSocket or SSE) for price updates, separate from the REST API for transactional operations
• Implement a pub-sub layer (Kafka or Redis Streams) that fans out market data events to WebSocket gateway servers
• Apply snapshot-plus-delta patterns: new clients receive the current state then subscribe to incremental price changes
• Design backpressure mechanisms to handle slow clients without affecting the broadcast to fast clients

3. Hot Symbol Contention

Popular stocks generate spikes of concurrent orders and reads that can overwhelm partition leaders and create bottlenecks.

Hints to consider:

• Partition the order book and processing by symbol, ensuring each symbol has a dedicated processing partition for sequential ordering
• Use read replicas and caches for price data so read-heavy traffic on popular symbols does not compete with order processing
• Implement rate limiting per user and per symbol to prevent runaway algorithmic trading from degrading service
• Design the order matching engine as a single-writer per symbol for correctness, with horizontal scaling across symbols

4. Multi-Step Order Lifecycle

Orders span validation, funds reservation, routing to exchange, execution, confirmation, and settlement, with each step potentially failing.

Hints to consider:

• Use a durable workflow engine or saga orchestrator that persists state at each step for reliable recovery after failures
• Implement compensating actions: void reservation if execution fails, reverse settlement if reconciliation detects errors
• Design the settlement process as a batch operation that runs after market close, reconciling executed orders with broker confirmations
• Log all state transitions as immutable audit events for regulatory compliance and dispute resolution

Suggested Approach

Step 1: Clarify Requirements

Confirm scope with the interviewer. Ask whether the system connects to real exchanges or operates as a simulated marketplace, whether margin trading and short selling are in scope, what order types to support (market, limit, stop), and whether after-hours trading is required. Clarify whether you need to design the order matching engine or can treat it as an external service. Establish regulatory requirements around audit trails, trade reporting, and data retention.