Phase 1: Requirements (5-10 min)
- Clarify scope (stocks only or options/crypto?)
- Understand latency requirements (microseconds!)
- Identify key features (matching, risk, compliance)

Phase 2: High-Level Design (10-15 min)
- Draw architecture: Order Gateway → Matching Engine → Settlement
- Explain data flow
- Discuss technology choices (C++, in-memory)

Phase 3: Deep Dive (15-20 min)
- Focus on 2-3 components:
  * Lock-free matching engine
  * ACID guarantees for trades
  * Market data distribution

Phase 4: Tradeoffs (5-10 min)
- In-memory vs persistent
- Lock-free vs locks
- Co-location vs cloud

Phase 5: Wrap-up (5 min)
- Regulatory compliance
- Monitoring and operations
- Future improvements

✓ "Achieve <1ms latency through co-location, kernel bypass, lock-free structures"
✓ "Use DPDK for kernel bypass networking (10x faster)"
✓ "In-memory order books with async persistence"
✗ Avoid: "Use cloud servers" (too slow)

Sample Answer:
"For ultra-low latency, I'll optimize every layer:

Hardware:
- Co-locate with exchange (<50 μs network)
- High-frequency CPUs (5+ GHz)
- Low-latency RAM (DDR5)
- 100 Gbps NICs

Network:
- Kernel bypass with DPDK (5-10 μs)
- RDMA for inter-server (<5 μs)
- Direct fiber to exchange

Software:
- Lock-free data structures (no contention)
- CPU pinning (no context switches)
- Huge pages (fewer TLB misses)
- Zero-copy operations

Matching Engine:
- In-memory order books
- Lock-free skip list for price levels
- Atomic operations for updates
- <500 μs matching time

Total: <1 millisecond end-to-end"

✓ "Use lock-free data structures with atomic operations"
✓ "Compare-and-swap (CAS) for updates"
✓ "FIFO order matching with price-time priority"
✗ Avoid: "Use mutex locks" (contention kills performance)

Sample Answer:
"For the matching engine, I'll use lock-free structures:

Order Book:
- Lock-free skip list for price levels
- Lock-free queue for orders at each price
- Atomic pointers for best bid/ask

Matching Algorithm:
1. New order arrives
2. Atomic read of best opposite side
3. If price matches:
   - Execute trade
   - CAS to update quantities
   - Retry if CAS fails
4. If no match:
   - CAS to insert in order book

Benefits:
- No lock contention
- High concurrency (1M orders/second)
- Predictable latency (<500 μs)
- Scales with cores

Implementation in C++:
std::atomic<Order*> best_bid;
while (!atomic_compare_exchange(&best_bid, &expected, &new_value)) {
    expected = atomic_load(&best_bid);
}

This achieves microsecond latency without locks."

✓ "Use write-ahead logging for durability"
✓ "Optimistic locking with version numbers"
✓ "Async persistence for performance"
✗ Avoid: "Eventual consistency for trades" (unacceptable)

Sample Answer:
"For ACID guarantees, I'll use WAL + optimistic locking:

Write-Ahead Log:
1. Write operation to log (sequential, fast)
2. Acknowledge to user
3. Apply to in-memory state
4. Async commit to database

Optimistic Locking:
UPDATE accounts 
SET balance = balance - :amount, version = version + 1
WHERE account_id = :id AND version = :expected_version;

If affected_rows = 0: Conflict, retry

Recovery:
1. Load latest snapshot
2. Replay WAL from snapshot
3. Rebuild state
4. Resume trading
Time: <1 second

Benefits:
- ACID compliance
- Fast commits (<1ms)
- Zero data loss
- Quick recovery"

✓ "Use UDP multicast for efficient fan-out"
✓ "Regional servers for 1M subscribers"
✓ "Delta encoding and compression (10x reduction)"
✗ Avoid: "Send full updates to each user" (doesn't scale)

Sample Answer:
"For market data distribution to 1M users:

Architecture:
Exchange → Gateway → Multicast → Regional Servers → Users

Multicast:
- UDP multicast (224.0.0.0/4)
- Single send reaches all regional servers
- No per-subscriber overhead
- 1 Gbps → 10 Gbps with multicast

Regional Servers:
- 100 servers globally
- 10K users per server
- Local caching
- <10ms latency

Optimization:
- Delta encoding (send only changes)
- Compression (10x reduction)
- Selective subscription (only subscribed symbols)
- Batching (group updates every 100 μs)

Throughput:
- 115K ticks/second from exchange
- 1M subscribers
- With optimization: 11.5B updates/second manageable

This scales linearly with regional servers."

❌ Bad: "Use cloud servers"
✓ Good: "Co-locate with exchange for <50 μs latency"

❌ Bad: "Use traditional database"
✓ Good: "In-memory with async persistence"

Key Point: Microseconds matter in HFT

❌ Bad: "Use mutex locks"
✓ Good: "Lock-free data structures with CAS"

❌ Bad: "Single-threaded matching"
✓ Good: "Lock-free parallel matching"

Key Point: Locks kill performance at scale

❌ Bad: "Eventual consistency for trades"
✓ Good: "ACID guarantees with WAL"

❌ Bad: "No transaction isolation"
✓ Good: "Serializable isolation level"

Key Point: Financial data requires strong consistency

❌ Bad: "No audit trail"
✓ Good: "Immutable audit log with 7-year retention"

❌ Bad: "No risk controls"
✓ Good: "Real-time risk checks before every order"

Key Point: Regulatory compliance is mandatory

"At HFT scale, every microsecond matters:

Latency Budget:
- Network: 50 μs (co-location)
- Validation: 20 μs
- Risk check: 100 μs
- Matching: 500 μs
- Response: 50 μs
Total: <1 millisecond

Optimization:
- Kernel bypass (DPDK): 10x faster
- Lock-free structures: No contention
- CPU pinning: No context switches
- Huge pages: Fewer TLB misses

Every optimization compounds for total 100x improvement."

"Beyond performance, compliance is critical:

1. Audit Trail:
   - Every order, trade, modification
   - Immutable Kafka log
   - 7-year retention
   - Nanosecond timestamps

2. Risk Controls:
   - Pre-trade checks
   - Position limits
   - Margin requirements
   - Circuit breakers

3. Reporting:
   - Daily to SEC/FINRA
   - Real-time monitoring
   - Automated compliance

4. Fair Access:
   - FIFO matching
   - No front-running
   - Equal treatment

This isn't optional, it's mandatory for operation."

Answer:
"Microsecond latency requires optimization at every layer:

1. Co-Location:
   - Servers in exchange data center
   - <50 μs network latency
   - Direct fiber connections

2. Kernel Bypass:
   - DPDK for networking
   - Poll mode (no interrupts)
   - Zero-copy operations
   - 10x faster than kernel

3. Lock-Free:
   - Atomic operations (CAS)
   - No mutex locks
   - No contention
   - Predictable latency

4. In-Memory:
   - Order books in RAM
   - No disk I/O
   - Pre-allocated memory
   - Cache-line aligned

5. CPU Optimization:
   - Pin threads to cores
   - NUMA-aware allocation
   - Huge pages (2 MB)
   - Branchless code

Result: <1 millisecond total latency"

Answer:
"Zero data loss through WAL + replication:

1. Write-Ahead Log:
   - Write to log before applying
   - Sequential writes (fast)
   - Durable storage (NVMe)
   - Sync every 1 second

2. Replication:
   - Real-time to secondary site
   - Event log streaming
   - <100ms lag

3. Snapshots:
   - Every 1 second
   - Consistent state
   - Fast recovery

4. Recovery:
   - Load snapshot: <500ms
   - Replay WAL: <500ms
   - Total: <1 second

5. Verification:
   - Checksums on all data
   - Validate on recovery
   - Detect corruption

Result: Zero data loss (RPO = 0), <1 second recovery (RTO)"

❌ "Use cloud for everything"
✓ "Co-locate matching engine, cloud for services"

❌ "Eventual consistency is fine"
✓ "ACID guarantees for trades"

❌ "Use Python for matching"
✓ "Use C++ for performance-critical code"

❌ "No need for audit trail"
✓ "Complete audit trail for compliance"

❌ "Locks are fine"
✓ "Lock-free for high concurrency"

"To summarize my stock trading platform:

1. Matching: Lock-free engine, <500 μs latency
2. Network: Co-location + DPDK, <50 μs
3. Storage: In-memory + async WAL, <1ms
4. Scale: 1M orders/second, 1M concurrent users
5. Compliance: Complete audit trail, risk controls

Key strengths:
- Microsecond latency
- ACID guarantees
- Regulatory compliant
- High availability (99.999%)

Trade-offs:
- High infrastructure cost ($17M/year)
- Complex operations
- Specialized hardware

Areas for improvement:
- ML for fraud detection
- Better risk models
- Options trading support

I'm happy to dive deeper into any component."