A trading platform receives a burst of market-data updates while thousands of customers submit orders. How should market-data distribution, order execution, risk checks and user-facing APIs be separated so that non-critical workloads cannot interfere with trading?

The separation, and the reason for each cut

Market data and order flow are different systems that happen to share a screen. Market data is high-volume, fan-out, lossy-tolerant and stateless per message. Order flow is low-volume, correctness-critical, stateful and must never be lost. Sharing infrastructure between them means the burst in the first starves the second.

The cuts that matter:

• Separate processes, pools and network paths. Not just separate services — separate connection pools, separate thread pools, separate queues. A shared pool is a shared fate regardless of how the code is organised.
• Market data is push, best-effort, and conflated. During a burst, a client that cannot keep up should receive the latest price, not a backlog of stale ones. Conflation is the correct backpressure response for market data and it is not available to order flow, which is why they cannot share a transport.
• Risk checks sit inline with orders but with a hard deadline and a defined failure behaviour. Pre-trade risk that can block indefinitely is a trading outage; pre-trade risk that fails open is a regulatory problem. The resolution is a fast local check on cached limits with an asynchronous authoritative reconciliation.
• Read APIs — portfolio, holdings, statements, charts — get their own replicas and their own capacity, and are the first thing shed. A customer who cannot see their portfolio during the open is unhappy; a customer who cannot place an order is harmed.

What degradation should look like

Static priority ordering, decided in advance and rehearsed: order placement and cancellation are never shed · position and risk updates degrade to lower frequency · market data conflates · portfolio views serve stale cached data · charts, reports and notifications are dropped entirely.

The property to design for is that the trading path's capacity does not depend on anything the other paths do. If a chart request can consume a connection the order path needs, the isolation is nominal.

The failure this prevents

The classic incident is not a trading system failing under trading load. It is a trading system failing because everyone opened the app at once — the burst of read traffic at market open exhausted a shared resource, and the orders queued behind portfolio queries.