30% offEnding soon
FSD-032Frontend system design Premium

Design a Financial Trading Terminal

Design a trading terminal with ordered market data, bounded rendering, exact prices, safe orders, alerts, reconnect recovery, and accessible failure states.

Advanced 61 min read

A financial trading terminal is two systems sharing one screen. The market-data side consumes a fast, ordered, entitlement-scoped stream and turns it into a bounded visual projection. The order side handles private, safety-critical commands whose states come only from an authoritative service. Keeping those lifecycles separate is the foundation of a trustworthy design.

A demo terminal can subscribe to a WebSocket and set React state for every quote. It looks convincing with ten symbols and a calm feed. Production pressure appears when thousands of messages arrive each second, one packet is missed, a reconnect starts a new session, a hidden tab stops painting, or an order acknowledgement crosses a stale market snapshot.

The interview is not a contest to name chart libraries. It is a test of whether the design preserves sequence, precision, account ownership, and user control while still feeling immediate.

Clarify the trading product and its authority

Assume a browser terminal for active but human-paced trading. Users maintain watchlists, inspect quotes and charts, create price and volume alerts, enter and amend orders, and monitor positions, balances, fills, and connection health. Market data may update far faster than the screen needs to paint. Orders are submitted to a trusted service that applies authentication, permissions, trading-session rules, tick and lot validation, risk checks, and venue routing.

Ask which instruments and markets are supported, whether data is delayed or real time, how entitlements vary by user, which order types exist, whether pre-trade risk checks are synchronous, and what actions are allowed when prices are stale. Also ask about desktop density, mobile scope, multi-window use, regulatory audit needs, and recovery objectives.

The design below gives desktop users a dense workspace and mobile users a focused monitor with guarded order actions. It does not put exchange credentials, risk rules, or authoritative balances in the browser.

The public interview prompt

Design a browser-based financial trading terminal. Explain:

  • snapshots, incremental market-data events, sequence numbers, gaps, reconnects, and stale-state policy;
  • workers, binary decoding, normalization, coalescing, rendering cadence, charts, watchlists, and memory limits;
  • decimal precision, currency, tick size, lot size, price formatting, and derived values;
  • order tickets, validation, idempotent submission, acknowledgements, fills, cancellation, and reconciliation;
  • private account streams, entitlements, risk controls, alerts, audit receipts, and multi-tab behavior;
  • keyboard navigation, color-independent status, live-region policy, responsive layouts, degraded states, telemetry, testing, and rollout.

What the premium solution covers

The complete solution begins with a feed-session receipt and follows ordered deltas through gap detection, snapshot repair, worker reduction, frame-bounded publication, and an accessible quote surface. It then separates that public market projection from private order and account state, including exact-value contracts, idempotent commands, risk gates, reconciliation, alerts, hidden tabs, and failure policy.

Original media includes a frame-verified sequence-recovery animation, a market-versus-account trust map, a rate-conversion visual, and a degraded-mode action matrix. A deterministic render-budget lab lets the reader vary feed rate, subscriptions, visible rows, paint cadence, decode cost, paint cost, and alert pressure.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

What is the central invariant in a browser trading terminal?
Every visible market value and order transition must belong to a known instrument, feed session, sequence position, precision contract, entitlement scope, and account. Late or replayed events may not silently replace newer state.
Should React render every market-data event?
No. Decode and reduce the full ordered stream outside React, coalesce the newest value by instrument and field, then publish an immutable batch at a bounded paint cadence. Orders and safety state use a separate immediate path.
What should the client do when a market-data sequence number is missing?
Stop publishing that affected stream, mark it stale, buffer only within a strict bound, request a fresh snapshot or supported replay, and resume only after the snapshot and following deltas form one continuous sequence.
Can a trading terminal use JavaScript numbers for prices and quantities?
Only when the full scaled-integer range and precision contract are proven safe. A safer boundary is decimal strings or scaled integers with explicit currency, tick size, lot size, and scale, followed by exact validation in a trusted order service.
Should an order appear filled optimistically?
No. The browser may show that a submission was received locally, but accepted, working, partially filled, filled, cancelled, and rejected states must come from the authoritative private order stream or reconciliation API.
How should a hidden browser tab handle live data?
Keep enough transport and sequence work to detect gaps, but suspend visual painting and nonessential calculations. On return, verify freshness and ownership, publish a current snapshot, and require explicit acknowledgement before risky actions if data is stale.