Node.js is single-threaded but non-blocking. The event loop has these phases in order:

// Event loop phases (each iteration = one "tick")
1. timers        — executes setTimeout / setInterval callbacks due now
2. pending I/O   — I/O callbacks deferred from previous iteration
3. idle/prepare  — internal Node use
4. poll          — retrieves new I/O events; executes their callbacks
5. check         — setImmediate() callbacks run here
6. close         — close events (socket.on('close', ...))

// Between each phase: process ALL microtasks first
// Microtasks = Promise .then() / .catch() + queueMicrotask()
// process.nextTick() runs before microtasks

Heavy CPU tasks block the event loop — use worker_threads for CPU-intensive work (e.g. computing Greeks across thousands of positions). I/O is handled by libuv's thread pool (default 4 threads), callback returns to poll phase.

// Promise.all — waits for ALL, short-circuits on first rejection
await Promise.all([fetchBalance(), fetchPositions(), fetchOrders()])
// Use when ALL results are needed (e.g. load dashboard data in parallel)

// Promise.allSettled — waits for ALL to finish regardless
const results = await Promise.allSettled([riskCheck(), marginCheck()])
results.forEach(r => r.status === 'fulfilled' ? r.value : r.reason)
// Use when partial failure is acceptable

// Promise.race — first one to settle wins (resolve OR reject)
await Promise.race([fetchMarketData(), timeout(2000)])
// Classic timeout pattern for latency-sensitive order APIs

// Promise.any — first SUCCESSFUL resolve wins
await Promise.any([primaryFeed(), backupFeed(), tertiaryFeed()])
// Great for redundant market data feeds with failover

Architecture approach:

• Horizontal scaling: Multiple Node.js instances behind a load balancer. Use sticky sessions (IP hash) so a client always hits the same node.
• Redis Pub/Sub: When a trade happens on node-1, publish to Redis. All other nodes subscribe and push to their connected clients.
• uWebSockets.js instead of the ws library — 10x lower memory per connection, written in C++.
• Connection housekeeping: Ping/pong heartbeats every 30s, terminate dead connections. Track subscriptions per connection (don't send BTC data to ETH traders).
• Message batching: Don't send one message per tick. Batch updates every 50–100ms per connection — reduces CPU, network, and client re-renders.

// Redis pub/sub pattern across Node.js instances
const publisher  = redis.createClient()
const subscriber = redis.createClient()

// On trade execution
publisher.publish('market:ETH-USDT', JSON.stringify(tradeData))

// Each WS node subscribes and fans out to its local connections
subscriber.subscribe('market:ETH-USDT', (msg) => {
  localClients.forEach(ws => ws.send(msg))
})

Backpressure occurs when a writable stream can't consume data as fast as a readable produces it. Without handling it, buffers grow unboundedly — memory leak / crash.

// pipe() handles backpressure automatically
readable.pipe(writable)

// Manual handling
const canWrite = writable.write(chunk)
if (!canWrite) {
  readable.pause()                       // stop producing
  writable.once('drain', () => readable.resume()) // resume when clear
}

Trading relevance: If you're writing tick data to PostgreSQL slower than WebSocket ticks arrive, backpressure management prevents data loss. In practice: buffer in Redis or Kafka (not memory), process in batches.

The crypto module provides cryptographic functionality that includes a set of wrappers for OpenSSL's hash, HMAC, cipher, decipher, sign, and verify functions.

const crypto = require('crypto');

// 1. Hashing (e.g. for generating deterministic IDs)
const hash = crypto.createHash('sha256')
                   .update('data')
                   .digest('hex');

// 2. HMAC Signing (Essential for Exchange API Auth)
function signRequest(payload, secret) {
  return crypto.createHmac('sha256', secret)
               .update(JSON.stringify(payload))
               .digest('hex');
}

// 3. Secure Random Bytes (for salts, session tokens)
const salt = crypto.randomBytes(16).toString('hex');

Buffers are used to handle binary data directly. In a trading system, WebSocket ticks or binary protocols (like Protobuf or FIX) are often processed as Buffers to avoid the overhead of string conversion.

// Allocating memory outside the V8 heap (more stable for large data)
const buf = Buffer.allocUnsafe(1024); // faster but contains old data

// Fast binary parsing
const price = buf.readDoubleBE(0);
const quantity = buf.readDoubleBE(8);

// TypedArrays for mathematical operations (Greeks, Indicators)
const priceHistory = new Float64Array(1000);

Benefits: Zero-copy operations, reduced Garbage Collection (GC) pressure, and direct memory access for high-speed network I/O.

Token bucket: bucket has capacity N. Tokens refill at rate R per second. Each request consumes 1 token. Request rejected if bucket empty.

class TokenBucketRateLimiter {
  constructor(capacity, refillRatePerSec) {
    this.capacity = capacity
    this.tokens   = capacity
    this.refillRate  = refillRatePerSec
    this.lastRefillTs = Date.now()
  }

  consume() {
    this._refill()
    if (this.tokens < 1) return false   // reject
    this.tokens -= 1
    return true
  }

  _refill() {
    const now     = Date.now()
    const elapsed = (now - this.lastRefillTs) / 1000
    const added   = elapsed * this.refillRate
    this.tokens   = Math.min(this.capacity, this.tokens + added)
    this.lastRefillTs = now
  }
}

// For distributed rate limiting: store tokens in Redis (INCR + TTL)
// Use Lua script for atomic check-and-decrement

// useMemo — memoizes a COMPUTED VALUE
const totalPnl = useMemo(() =>
  positions.reduce((sum, p) => sum + p.unrealizedPnl, 0),
  [positions]   // only recomputes when positions array changes
)

// useCallback — memoizes a FUNCTION REFERENCE
const handleCancel = useCallback((orderId) => {
  cancelOrder(orderId)
}, [cancelOrder])  // stable reference → child wrapped in React.memo won't re-render

// ⚠ Trap: both have COST (comparison work every render)
// Only use when: (1) expensive computation or (2) preventing child re-renders
// Don't wrap every value/function — profile first

This is exactly what Pi42 needs. Your answer should cover four layers:

• 1. Virtual scrolling: Only render visible rows. Use react-virtual or react-window. Rendering 200 DOM nodes vs 10,000 is ~20x faster.
• 2. Throttled WebSocket → state: Don't setState on every tick. Buffer updates in a ref, flush to state via requestAnimationFrame at 60fps max.
• 3. React.memo + stable keys: Wrap row component in React.memo with price-level key. Only rows whose data changed re-render.
• 4. Immutable update pattern: Use shallow copy for changed rows only — structural sharing keeps reconciliation O(changed) not O(all).

const wsBuffer = useRef([])

useEffect(() => {
  const ws = new WebSocket('wss://api.pi42.com/orderbook')
  ws.onmessage = (e) => wsBuffer.current.push(JSON.parse(e.data))

  const rafId = requestAnimationFrame(function flush() {
    if (wsBuffer.current.length > 0) {
      setOrderBook(prev => applyUpdates(prev, wsBuffer.current))
      wsBuffer.current = []
    }
    requestAnimationFrame(flush)
  })
  return () => { ws.close(); cancelAnimationFrame(rafId) }
}, [])

React builds a virtual DOM tree. On state change, it creates a new tree and diffs it against the previous (reconciliation). Differences get applied to real DOM (commit phase).

Unnecessary re-render triggers:

• Parent re-renders → all children re-render unless wrapped in React.memo
• New object/array/function reference in props on every render (common with inline { } or () => {})
• Context value changing reference even if data is the same
• Wrong key — using array index as key causes full re-mount when list order changes

-- Range partition by month — keeps each partition small & manageable
CREATE TABLE trades (
  id          BIGSERIAL,
  symbol      VARCHAR(20)    NOT NULL,
  user_id     BIGINT        NOT NULL,
  order_id    BIGINT        NOT NULL,
  side        VARCHAR(4)     NOT NULL,  -- 'buy' | 'sell'
  price       NUMERIC(20,8) NOT NULL,
  quantity    NUMERIC(20,8) NOT NULL,
  fee         NUMERIC(20,8) NOT NULL,
  created_at  TIMESTAMPTZ   NOT NULL DEFAULT NOW(),
  PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

CREATE TABLE trades_2025_05 PARTITION OF trades
  FOR VALUES FROM ('2025-05-01') TO ('2025-06-01');

-- Indexes (on the parent — cascade to all partitions)
CREATE INDEX idx_trades_user_time  ON trades (user_id, created_at DESC);
CREATE INDEX idx_trades_sym_time   ON trades (symbol, created_at DESC);

-- For P&L queries: use NUMERIC not FLOAT (exact decimal arithmetic)
-- For mark price: store separately, never derived from trades table

For trading systems: Use SERIALIZABLE or SELECT FOR UPDATE (row-lock) for balance deductions and margin checks. Never allow a race condition where two orders both pass a margin check simultaneously and both consume the same collateral.

BEGIN;
SELECT available_margin FROM accounts
  WHERE user_id = 123
  FOR UPDATE;          -- locks this row until transaction ends
-- check if margin sufficient
UPDATE accounts SET available_margin = available_margin - :required
  WHERE user_id = 123;
COMMIT;

Use a sorted map (price → queue of orders). Bids descending, asks ascending.

class OrderBook {
  constructor() {
    this.bids = new Map()  // price → [orders] — sorted desc externally
    this.asks = new Map()  // price → [orders] — sorted asc
    this.bidPrices = []    // sorted desc
    this.askPrices = []    // sorted asc
  }

  addOrder(order) {
    const book = order.side === 'buy' ? this.bids : this.asks
    if (!book.has(order.price)) {
      book.set(order.price, [])
      this._insertSorted(order.side, order.price)
    }
    book.get(order.price).push(order)  // price-time priority: FIFO per level
  }

  getBestBid() { return this.bidPrices[0] }
  getBestAsk() { return this.askPrices[0] }
  getSpread()  { return this.getBestAsk() - this.getBestBid() }

  match(incomingOrder) {
    const oppSide = incomingOrder.side === 'buy' ? this.asks : this.bids
    const prices  = incomingOrder.side === 'buy' ? this.askPrices : this.bidPrices
    const trades  = []
    let   remaining = incomingOrder.quantity

    while (remaining > 0 && prices.length > 0) {
      const bestPrice = prices[0]
      if (incomingOrder.side === 'buy'  && bestPrice > incomingOrder.price) break
      if (incomingOrder.side === 'sell' && bestPrice < incomingOrder.price) break

      const queue = oppSide.get(bestPrice)
      while (queue.length > 0 && remaining > 0) {
        const resting = queue[0]
        const fillQty = Math.min(remaining, resting.quantity)
        trades.push({ price: bestPrice, quantity: fillQty, ... })
        resting.quantity -= fillQty
        remaining       -= fillQty
        if (resting.quantity === 0) queue.shift()
      }
      if (queue.length === 0) { oppSide.delete(bestPrice); prices.shift() }
    }
    return trades
  }
}

// EMA formula: EMA(t) = price(t) * k + EMA(t-1) * (1 - k)
// k = 2 / (period + 1)   — smoothing factor
// O(1) per tick, O(1) memory — no sliding window needed

class EMA {
  constructor(period) {
    this.k   = 2 / (period + 1)
    this.ema = null
  }

  update(price) {
    if (this.ema === null) { this.ema = price; return this.ema }
    this.ema = price * this.k + this.ema * (1 - this.k)
    return this.ema
  }
}

const ema20 = new EMA(20)
ticks.forEach(t => ema20.update(t.close))

Key design decisions to mention:

• Single-threaded per symbol: The matching engine for ETH-USDT is one process. No locks needed — sequential processing guarantees correctness. Scale by adding processes for new symbols.
• In-memory order book: All active orders in memory. PostgreSQL is the persistent store — write order on creation, update on fill/cancel. Recovery: replay Kafka log from last checkpoint to rebuild in-memory state.
• Kafka partitioned by symbol: Guarantees ordered delivery per symbol. Consumers (matching engine) process in sequence — no race conditions.
• Separate balance check from matching: Balance/margin pre-checked at ingress. Matching engine trusts it. Balance service deducts atomically after trade event.
• Mark price vs last trade price: Liquidation checks use mark price (index-based average of spot exchanges) to prevent manipulation. Stored and updated separately from the order book.

Core formula:

-- Unrealized P&L (long position)
unrealized_pnl = (mark_price - avg_entry_price) × qty × contract_multiplier

-- Realized P&L (on close)
realized_pnl = (exit_price - avg_entry_price) × closed_qty × multiplier - fees

Architecture:

• Price tick source: Kafka topic market.price.{symbol} updated every 100ms from aggregated index.
• P&L service: Consumes price ticks. For each tick, fetches all open positions for that symbol from Redis (not DB — too slow). Computes P&L, writes result to Redis hash: user:{id}:pnl:{symbol}.
• WebSocket push: Separate WS service. Subscribes to Redis keyspace notifications. When P&L key updates, pushes delta to connected user.
• Cold path: PostgreSQL for historical P&L, end-of-day reports, audit trail.

Two-path design — fast path + safe path:

Liquidation engine:

• Monitor margin ratio = maintenance_margin / account_equity continuously
• When ratio falls below threshold: place liquidation market order, cancel all open orders first
• Use mark price, not last traded price — prevents liquidation cascades from manipulated spot trades
• Insurance fund absorbs losses when liquidation price is worse than bankruptcy price

Funding rate mechanics:

• Calculated every 8 hours (or 1 hour on some exchanges)
• If perp price > spot: funding is positive → longs PAY shorts (discourages buying, pulls price down)
• If perp price < spot: funding is negative → shorts PAY longs (discourages selling, pushes price up)
• Rate = (perp − spot) / spot × dampening factor

// Example: ETH at $3000, 10x leverage, 1 ETH long position

Position value   = $3,000
Initial margin   = $3,000 / 10x = $300      // collateral deposited
Maint. margin    = $3,000 × 0.5% = $15       // minimum to stay open

Liquidation price = entry − (initial_margin − maint_margin) / qty
                  = $3000 − ($300 − $15) / 1
                  = $2,715

// If ETH drops to $2,715 → liquidation
// Bankruptcy price = $3000 − $300 = $2700 (full loss)
// Insurance fund covers gap between $2,715 and $2,700

Cross margin vs Isolated margin:

• Isolated: Only the allocated margin for this position is at risk. Liquidated position cannot drain your whole account.
• Cross: All account equity is available as margin. Harder to get liquidated but whole account at risk.

Mark price = index price (weighted average of ETH price across major spot exchanges) + EMA of basis (perp − spot). It is designed to be manipulation-resistant.

Why not use last traded price for liquidations?

• A large trader could place a large market sell on the exchange to briefly crash last traded price
• This could trigger thousands of stop-losses and liquidations
• Those liquidations cascade and crash the price further (cascade liquidation event)
• Mark price cannot be manipulated easily — it's anchored to global spot prices across exchanges