The LMAX Architecture

Ideas you will meet

Distributed Systems

Consensus, time, failure and the fundamentals of scale-out.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Real-World Systems · 13 minDesign a stock exchangeAn order book, a matching engine and a sequencer: how an exchange matches buyers and sellers fairly in microseconds.Read hereClose

  The problem

  An exchange lets buyers and sellers trade. Participants submit orders; the exchange matches them and reports the trades.

  Key properties:

  • Fairness: orders are handled in a strict, auditable order.
  • Very low latency: microseconds from order to acknowledgment.
  • High throughput: hundreds of thousands to millions of orders per second at peaks.
  • Correctness and durability: money is involved. No lost or duplicated trades.
  • Availability: an exchange outage halts a market.

  The order book

  For each symbol the order book holds resting orders:

  • Bids (buy orders), highest price first.
  • Asks (sell orders), lowest price first.
  • Within a price level, orders queue by arrival time.

  Common order types: limit (a worst price you accept; unmatched part rests in the book) and market (take the best available now).

  Matching: price-time priority

  An incoming buy matches the lowest-priced asks it can afford; among equal prices the earliest order matches first. Matching repeats until the order is filled or no longer matches, and any remainder rests in the book.

  Image: Thomas J. O'Halloran · Public domain · Source · Wikimedia Commons: NY stock exchange traders floor LC-U9-10548-6

  Architecture

  100%

  Figure SDA-RWS-05-1 · Exchange: gateway, sequencer, matching engine · © forcsguy.com

  1. Gateways authenticate participants, validate orders, and run pre-trade risk checks (limits, available funds).
  2. The sequencer gives every event a sequence number: one agreed total order, the basis of fairness and recovery.
  3. A matching engine applies events in order to the in-memory order book and emits trades.
  4. Everything is written to a durable event log. Executions go to participants, and a market data stream tells everyone about prices and depth.
  5. Clearing and settlement later move money and securities between accounts.

  100%

  Figure SDA-RWS-05-2 · An order book with a buy order sweeping the sell side · © forcsguy.com

  How it gets so fast

  • In-memory order books and no database in the critical path.
  • Single-threaded matching per symbol group: no locks, deterministic behaviour. Parallelism comes from partitioning symbols across engines.
  • Event sourcing: state is the result of applying an ordered log. Persist the event first (to a memory-mapped file or replicated log), then process.
  • Pre-allocated memory, ring buffers, no garbage-collection pauses, and careful cache-friendly data structures.
  • Hardware and network: servers co-located in the exchange's data centre, fast network cards and kernel-bypass networking, precise time sources.

  100%

  Figure SDA-RWS-05-3 · A fast engine on one machine: shared log and busy loops · © forcsguy.com

  Reliability

  • A hot standby applies the same event log and can take over within moments. Use sequence numbers to detect gaps and avoid duplicate processing.
  • Replicate the log across machines or sites before acknowledging, trading a little latency for durability.
  • Idempotent order identifiers prevent a resubmitted order executing twice.
  • Circuit breakers halt trading when prices move too fast.

  Market data fairness

  Everyone should see the same information at about the same time. Exchanges publish through multicast feeds, give all participants equal-length cables inside the data centre, and timestamp events at the matching engine. A separate, slower snapshot and retransmission service helps receivers that miss packets.

  What is out of scope here

  Clearing houses, settlement cycles, regulation and surveillance are large systems of their own. The core design is the sequencer plus deterministic matching engine plus durable log.

  Real-world reading

  Related reading

  • Event SourcingMartin FowlerBlogs
  • Monolith FirstMartin FowlerBlogs
  • Rewriting the heart of our sync engineDropboxCase Studies
  • Cape: Event Stream Processing Framework at DropboxDropbox engineers · DropboxCase Studies

  Show 6 moreShow fewer

  • Improving Search Engine Efficiency by over 25% at eBayeBay engineers · eBayCase Studies
  • Finding Kafka throughput limit in infrastructure at DropboxDropbox engineers · DropboxCase Studies
  • Bullet: Forward-Looking Query Engine for Streaming Data at YahooYahoo engineers · YahooCase Studies
  • MicroservicesJames Lewis and Martin Fowler · Martin FowlerBlogs
  • The LMAX ArchitectureMartin FowlerCase Studies
  • Microservices and OrchestrationMartinfowler engineers · MartinfowlerCase Studies

  Open this lesson with its quiz and exercise