Market Maker Service — Engineering Guide

Service Name: Market Maker Service (MMS) Audience: Backend engineers, platform engineers, ops, risk, reviewers Scope: Derivatives / Perpetual Futures Purpose: Understanding how MMS works and how it fits into the exchange

1. What Is the Market Maker Service?

The Market Maker Service (MMS) is a system-owned automated trader whose sole responsibility is to provide liquidity to the exchange.

It behaves like a normal trading participant, but:

• Uses system capital
• Is fully controlled
• Is risk-limited
• Is auditable
• Has no special privileges

Think of MMS as a robot trader operated by the exchange, not a core engine component.

2. Why Do We Need a Market Maker?

Without market makers:

• Order books become thin
• Spreads widen
• Small trades cause large price jumps
• New markets look “dead”

MMS helps by:

• Keeping both bid and ask available
• Maintaining minimum depth
• Reducing sudden gaps
• Improving user experience

3. What MMS Is NOT (Very Important)

MMS does not:

• Control prices
• Modify the order book directly
• See hidden orders
• Get matching priority
• Touch user funds
• Influence mark price, index price, or funding
• Participate in liquidation logic

MMS failing should only reduce liquidity — it must never affect correctness or safety of the exchange.

4. How MMS Fits into the Exchange Architecture

graph LR MD[Market Data] --> MM[Market Maker] MM --> OS[Order Service] OS --> ME[Matching Engine] ME --> Events[Order Events] Events --> MM Events --> Wallet[Wallet / Position]

Key Idea

MMS is outside the core trading engine.

It:

1. Observes the market
2. Decides what orders to place
3. Sends orders like any other trader
4. Reacts to fills and updates its state

5. Market Maker Account Model

MMS trades using a dedicated system account:

• Account type: SYSTEM_MARKET_MAKER
• Separate wallet
• Separate ledger
• Separate risk limits
• No withdrawals

This ensures:

• Clean accounting
• Clear audit trail
• No mixing with user funds

6. High-Level Responsibilities

MMS performs four core functions:

1. Market Observation

• Reads order book (L2)
• Tracks trades
• Measures spread and volatility

2. Quote Generation

• Computes fair price (mid)
• Applies target spread
• Adjusts prices based on inventory
• Produces one bid and one ask

3. Order Management

• Places new orders
• Cancels stale orders
• Avoids order spam
• Handles rejections safely

4. Risk Protection

• Tracks inventory and PnL
• Enforces exposure limits
• Stops immediately on anomalies

7. Actor Model (How MMS Is Structured Internally)

MMS runs one independent worker per symbol.

Example:

• BTCUSDT-PERP → Worker A
• ETHUSDT-PERP → Worker B

Each worker:

• Is single-threaded
• Owns its own state
• Never shares mutable data

This ensures:

• Deterministic behavior
• No race conditions
• Easy reasoning and debugging

8. Market Data Flow

MMS consumes:

• Order book snapshots
• Order book deltas
• Trade events

From these, it computes:

• Best bid / ask
• Mid price
• Spread
• Rolling volatility

If data becomes:

• Stale
• Inconsistent
• Crossed

➡ MMS pauses trading for that symbol automatically

9. How Quotes Are Computed (Conceptually)

At a high level:

1. Take mid price from order book
2. Apply configured spread
3. Adjust prices based on inventory
4. Clamp prices to safety bands
5. Place bid and ask orders

The goal is:

• Stay close to the market
• Encourage trades that reduce exposure
• Avoid aggressive or manipulative behavior

10. Inventory Awareness (Key Concept)

MMS always tracks its net position per symbol.

• If inventory ≈ 0 → quote symmetrically
• If inventory is long → encourage selling
• If inventory is short → encourage buying

This is done by shifting both bid and ask prices, not widening the spread.

Result:

• Inventory naturally rebalances
• No sudden directional risk

11. Order Lifecycle

For each symbol, MMS maintains:

• At most one active bid
• At most one active ask

When market changes:

1. Desired quote prices are recalculated
2. Existing orders are compared
3. Only necessary cancels/creates happen

This avoids:

• Order churn
• Engine overload
• Self-induced volatility

12. Risk Controls (Why MMS Is Safe)

MMS has hard guardrails:

Exposure Limits

• Max position per symbol
• Max total exposure
• Max drawdown

Kill Switches

Triggered on:

• Exposure breach
• Loss breach
• Market halt
• Market data failure
• Kafka lag
• Order rejection storms

When triggered:

Cancel all orders
Pause trading
Emit alerts

No retries. No guessing.

13. States of a Symbol in MMS

Each symbol can be in one of:

• ACTIVE → Normal quoting
• PAUSED → No trading, safe state
• HALTED → Emergency stop, manual intervention required

Default state on startup is PAUSED.

14. Startup & Recovery Behavior

On service start or restart:

1. Load configs
2. Rebuild inventory from order events
3. Cancel any leftover orders (best effort)
4. Set all symbols to PAUSED
5. Wait for explicit resume

This ensures:

• No accidental trading
• No duplicate orders
• Predictable recovery

15. Shadow Mode (Safety Feature)

MMS supports shadow mode.

In shadow mode:

• Quotes are computed
• Orders are NOT placed
• Events are emitted for analysis

Used for:

• Testing strategies
• Validating configs
• Safe dry runs

16. Observability & Transparency

MMS exposes:

• Inventory metrics
• Spread metrics
• PnL metrics
• Kill switch counters

All orders are:

• Tagged as market maker
• Fully auditable
• Replayable from events

17. Operational Philosophy

MMS follows a conservative philosophy:

• It is better to stop trading than to trade incorrectly
• Liquidity loss is acceptable
• Market integrity loss is not
• Humans must always be able to intervene

18. Common Questions

”Can MMS manipulate the market?”

No. It:

• Uses public data only
• Trades through normal pipelines
• Has no privileged access

”What happens if MMS crashes?”

Nothing breaks:

• Orders are canceled
• Liquidity temporarily reduces
• Core trading continues normally

”Can MMS cause losses?”

Losses are:

• Strictly capped
• Monitored
• Isolated to system funds

19. Summary

The Market Maker Service is:

• A liquidity provider
• A regular participant
• A risk-contained system
• A non-critical component
• A fully auditable automation

Its failure mode is graceful degradation, never systemic risk.

20. Where to Look Next

If you want to go deeper:

• Market Maker Service Documentation - Technical implementation details
• Market Maker API Reference - REST API endpoints
• Kafka Events Documentation - Market maker events
• Architecture Overview - System architecture

Final Note

The Market Maker Service should never be clever. It should be predictable, boring, and safe.

That is exactly how a production exchange should operate.