Bird
Raised Fist0

Design a Stock Exchange - Order Book, Matching Engine, Market Data Feed

HLDhardInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Kafka Order Ingestor

Receive new buy order

Accepts client order and publishes it to Kafka Order Queue

Protocol:Kafka
BeforeNo new order present in Kafka Order Queue
AfterNew buy order durably stored in Kafka Order Queue
Kafka Order Queue

Store order

Durably logs the new buy order for processing by Matching Engine

Protocol:Kafka
BeforeOrder queue contains previous orders only
AfterOrder queue contains new buy order appended
Matching Engine

Fetch and match order

Consumes order from Kafka queue, matches against existing orders

Protocol:Kafka + Internal RPC
BeforeOrder book has existing sell orders, no new buy order matched
AfterMatching Engine identified matches and generated trades
Order Book Store

Update order book

Apply matched trades and update order book state persistently

Protocol:Internal RPC
BeforeOrder book reflects previous state without new trades
AfterOrder book updated with matched trades and remaining orders
Market Data Publisher

Publish market data

Sends updated order book and trade info to subscribers

Protocol:WebSocket
BeforeSubscribers have last known market data snapshot
AfterSubscribers receive real-time market data update
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│ Kafka Order Ingestor  │
│  - consumes orders    │
└──────────┬────────────┘
           │ Kafka
           ▼
┌───────────────────────┐
│ Kafka Order Queue     │
│  - durable order log  │
└──────────┬────────────┘
           │ Kafka
           ▼
┌───────────────────────┐
│ Matching Engine       │
│  - matches orders     │
└──────────┬────────────┘
           │ Internal RPC
           ▼
┌───────────────────────┐
│ Order Book Store      │
│  - stores order book  │
└──────────┬────────────┘
           │ Internal RPC
           ▼
┌───────────────────────┐
│ Market Data Publisher │
│  - publishes updates  │
└──────────┬────────────┘
           │ WebSocket
           ▼
┌───────────────────────────┐
│ Market Data Subscribers    │
│  - receive market data     │
└───────────────────────────┘
Design Rationale

This architecture shows a vertical flow of a new buy order through the stock exchange system. The Kafka Order Ingestor receives the order and publishes it to a durable Kafka Order Queue, ensuring reliable ingestion. The Matching Engine consumes orders from Kafka, matches buy and sell orders, and generates trades. It then updates the persistent Order Book Store with the new state reflecting matched trades. Finally, the Market Data Publisher broadcasts real-time market data updates to subscribers over WebSocket connections. This design decouples ingestion, matching, storage, and publishing, enabling scalability and fault tolerance. Kafka provides durability and ordering guarantees, while internal RPC calls ensure low-latency communication between core components.

Primary Focus

✓

Practice

(1/5)
1. A deployment system must ensure zero downtime during releases by switching traffic instantly between two identical environments. Which deployment strategy best fits this requirement?
easy
A. Rolling deployment updating servers one by one
B. Canary deployment with gradual traffic shifting to new version
C. Feature flags toggling new features on the same environment
D. Blue-Green deployment with instant switch of load balancer target

Solution

  1. Step 1: Identify zero downtime requirement

    Blue-Green deployment uses two identical environments and switches traffic instantly, ensuring zero downtime.

  2. Step 2: Eliminate other options

    Canary is gradual, not instant; Feature flags don't switch entire environments; Rolling updates cause partial downtime.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Blue-Green switches environments instantly for zero downtime [check]
Hint: Instant switch between identical environments is Blue-Green [OK]
Common Mistakes:
2. A distributed system requires a lock mechanism that ensures mutual exclusion across multiple Redis instances with minimal risk of deadlocks. Which component or approach best handles this requirement?
easy
A. Implement Redlock algorithm coordinating locks across multiple Redis masters
B. Use a relational database row lock with distributed transactions
C. Use a single Redis instance with SETNX and expire for locking
D. Use a centralized ZooKeeper lock service for distributed locking

Solution

  1. Step 1: Understand distributed lock requirements

    Single Redis instance with SETNX risks single point of failure and split-brain issues.

  2. Step 2: Evaluate Redlock's multi-instance coordination

    Redlock uses multiple Redis masters to reduce risk of deadlocks and ensure safety under partial failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Redlock coordinates multiple Redis masters for safer distributed locks [check]
Hint: Multiple Redis masters coordinated -> safer distributed locks [check]
Common Mistakes:
3. For a distributed counter requiring strong eventual consistency and minimal coordination, which architecture is best suited?
medium
A. Use sharded CRDT counters replicated asynchronously with conflict-free merges
B. Use a centralized counter service with distributed locks to serialize increments
C. Use a distributed database with linearizable transactions for each increment
D. Use a message queue with exactly-once delivery and synchronous aggregation

Solution

  1. Step 1: Evaluate coordination and consistency trade-offs

    Centralized locks (A) and linearizable transactions (C) impose coordination and reduce availability. Message queues with synchronous aggregation (D) add latency and bottlenecks.

  2. Step 2: Recognize sharded CRDT counters provide eventual consistency with no coordination

    They allow concurrent increments and asynchronous merges, fitting minimal coordination and strong eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Sharded CRDTs enable coordination-free eventual consistency [check]
Hint: CRDTs avoid coordination, unlike locks or linearizable DBs [check]
Common Mistakes:
4. If the Kafka cluster responsible for location update ingestion becomes unavailable, what is the immediate failure observed in the system?
medium
A. Location updates queue up in the WebSocket Server memory until Kafka recovers
B. WebSocket Server blocks on sending updates, causing client-side UI to freeze
C. Location updates are lost silently without any retry or backpressure
D. Clients receive stale location data but no error is shown

Solution

  1. Step 1: Understand Kafka's role in ingestion

    Kafka decouples ingestion; if unavailable, producers (WebSocket Server) cannot push messages.

  2. Step 2: Trace failure impact

    WebSocket Server buffers updates temporarily but memory is limited; blocking would cause backpressure but usually async buffers exist.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka outage causes buffering, not silent loss or blocking immediately [check]
Hint: Kafka outage -> WebSocket buffers updates temporarily [check]
Common Mistakes:
5. For a mobile chat app requiring exactly-once message delivery with minimal latency, which architecture is best suited?
medium
A. Use Kafka with transactional producers and consumers for exactly-once semantics
B. Use at-most-once delivery with client retries on failure
C. Use polling-based delivery with sequence numbers for ordering
D. Use a message queue with idempotent consumers and client-side deduplication

Solution

  1. Step 1: Evaluate Kafka transactions for mobile clients

    Kafka's transactional exactly-once requires stable connections and complex coordination, unsuitable for mobile clients with intermittent connectivity.

  2. Step 2: Assess idempotent consumers with client deduplication

    Idempotent consumers combined with client-side deduplication handle retries and duplicates gracefully, fitting mobile constraints and ensuring exactly-once delivery.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Idempotency + client deduplication -> practical exactly-once for mobile [check]
Hint: Mobile needs idempotency + deduplication, not Kafka transactions [OK]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard