System Design: Designing a Stock Ticker & Trading System

Stock trading systems are among the most demanding distributed systems in the world.

They must handle:

• Millions of real-time price updates
• Thousands of trades per second
• Strict correctness guarantees
• Ultra-low latency
• Zero tolerance for inconsistency

In this article, we’ll design a scalable stock ticker + trading system, step by step, from an interview perspective.

Step 1: Clarify Requirements (Critical in Interviews)

Functional Requirements

• Show real-time stock prices (ticker)
• Allow users to place buy/sell orders
• Support market and limit orders
• Match orders correctly
• Confirm trades instantly
• Persist trades for audit & reporting

Non-Functional Requirements

• Ultra-low latency (milliseconds)
• High throughput
• Strong consistency for trades
• Fault tolerance
• High availability
• Horizontal scalability

Interview tip: Price display can be eventually consistent. Trade execution must be strongly consistent.

Step 2: High-Level Architecture

Core Components

• API Gateway
• Market Data Service
• Order Management System (OMS)
• Matching Engine
• Trade Execution Service
• Message Broker (Kafka)
• Cache (Redis)
• Databases
• WebSocket Server

Step 3: Real-Time Stock Ticker Design

Flow

1. Stock exchanges publish price updates
2. Market Data Service consumes feeds
3. Prices are normalized & processed
4. Latest prices cached in Redis
5. Updates pushed to clients via WebSockets

Why WebSockets?

• Low latency
• Persistent connection
• Efficient real-time streaming

Polling is a hard NO at scale.

Step 4: Market Data Storage

• Redis → Latest prices (hot data)
• Time-series DB → Historical prices
• Kafka → Price update streams

This separation ensures:

• Fast reads
• Reliable replay
• Scalable consumers

Step 5: Order Placement API

Place Order

POST /orders

{
  "userId": "123",
  "symbol": "AAPL",
  "side": "BUY",
  "type": "LIMIT",
  "price": 180,
  "quantity": 10
}

Validations:

• User balance
• Stock availability
• Order parameters

Step 6: Order Management System (OMS)

Responsibilities:

• Validate orders
• Persist order state
• Send orders to matching engine
• Track order lifecycle

Order states:

NEW → PARTIALLY_FILLED → FILLED / CANCELLED

OMS must be:

• Strongly consistent
• Idempotent
• Transaction-safe

Step 7: Matching Engine (The Heart)

Order Book

• Buy orders → Max Heap (highest price first)
• Sell orders → Min Heap (lowest price first)

Matching Logic

• Price-time priority
• Match until:
• Quantity fulfilled
• No compatible order exists

One symbol = one matching engine thread This avoids race conditions.

Step 8: Consistency & Concurrency

Trade execution requires:

• Strong consistency
• No double spending
• No partial trades

Techniques:

• Single-threaded matching per symbol
• Database transactions
• Idempotent APIs
• Sequence numbers

This is where simplicity beats parallelism.

Step 9: Trade Execution Flow

1. Match found
2. Trade created
3. Balances updated atomically
4. Trade persisted
5. Notifications sent
6. Order book updated

Failures here are not acceptable.

Step 10: Notifications & Updates

• Trade confirmations (WebSocket / Push)
• Order status updates
• Price alerts

Use async processing via Kafka to avoid blocking trades.

Step 11: Scaling the System

Scale Market Data

• Partition Kafka topics by symbol
• Multiple consumers
• CDN for delayed public feeds

Scale Trading

• Shard by stock symbol
• Independent matching engines
• Horizontal OMS scaling

Step 12: Failure Handlig & Recovery

• Kafka replay for missed events
• Snapshots of order books
• Circuit breakers for external feeds
• Graceful degradation for ticker (not trades)

Step 13: Observability & Monitoring

Track:

• Order latency
• Match time
• Trade success rate
• Price feed lag
• Queue depth

Alerts must trigger before users notice.

Step 14: Security & Compliance

• Authentication & authorization
• Rate limiting
• Audit logs
• Regulatory compliance (SEBI / SEC)
• Encryption in transit & at rest

Final Interview Takeaway

A stock trading system is two systems in one:

• Ticker system → fast, scalable, eventually consistent
• Trading system → strict, correct, strongly consistent

You can be slow and correct. You can be fast and wrong. But you can never be wrong and fast in trading.

That’s why trading systems prioritize correctness over raw speed.