Why a web trading terminal loses orders during peak hours
In a calm market, the terminal looks healthy: the order book updates, candles move smoothly, an order goes out in fractions of a second.
Peak load breaks this picture first — the quote stream during news events grows by an order of magnitude, the interval between book updates shrinks to dozens per second, and the web trading terminal stops keeping up with the data source.
The most expensive failure is order book desynchronization. If the book is assembled from individual deltas without checking the sequence number against the snapshot, one lost or late delta leaves volumes on the screen that are no longer there. The trader sees liquidity, sends an order — and gets filled at a completely different price.
Chart lag goes alongside: redrawing candles and recalculating indicators are performed in the same computational thread as order book processing.
Frames pile up in a queue, and during a spike the chart shows the state from several seconds ago — you can no longer set a stop or act on a breakout from it.
Duplicate orders and session drops close the list. Repeating a request on timeout without an idempotency key creates a second order, and a connection break during a peak leads to reconnection with a full book reload and loss of position context.
We explain how this is resolved: from stream integrity checks to reconnection without losing session state.
What a reworked terminal delivers: the effect in metrics
Metrics were taken before and after the rework on the same scenario: peak order flow, several instruments open at the same time, forced connection breaks.
The comparison was based on five values — rendering speed, share of lost updates, recovery time, session stability, and the class of failures that was fully eliminated.
Rendering speed no longer depends on event density.
Order book and chart updates are grouped into a single frame, so an order spike does not turn into a task queue: the interface remains responsive, and the delay between data arrival and its appearance on screen has been reduced severalfold.
Lost updates were the main cause of wrong decisions: when the connection broke, the terminal kept showing an outdated picture.
Now, after reconnection, the state is reconciled with a full order book snapshot and the changes for the missed interval, so divergence from the exchange state does not accumulate.
Recovery time is measured without reloading the page. The session survives a disconnection, open forms and chart settings remain in place, and return to a working state takes just seconds instead of logging in again and reconfiguring manually.
The eliminated class of failures — “the interface froze during a spike” and “data on screen became outdated.” It is resolved by decoupling the data stream and rendering: a failure in one channel does not stop the other.
Session stability is confirmed by long runs without page reload — this value shows the effect of the rework immediately.
Terminal build options: custom interface, ready-made module, hybrid
The key fork is not budget, but the depth of control over the order book and order matching. If the terminal only displays quotes and passes orders to the broker, a ready-made core covers the task; if custom execution logic is needed, the zone of custom development begins. Below are three scenarios with their ceilings.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Ready-made module | Trading logic is standard, launch is needed within a tight timeframe, the set of instruments and order types is typical | Order book customization is limited by the provider's settings, you cannot embed your own order routing inside, and the depth of the display is fixed |
| Custom development | Non-standard order types are needed, custom order matching logic, and multiple venues combined in one window | Longer to first working release; load, failure recovery, and trade history are handled by us |
| Hybrid scheme | A ready-made core maintains the data stream, while a custom layer is responsible for the display, order book, and order matching | Requires a strict boundary between zones: without it, a provider update breaks the customizations |
In practice, order matching determines the choice: a ready-made module does not let you control execution priority, so with non-standard scenarios it hits the ceiling first. The hybrid scheme bypasses this limitation — the custom layer can be changed independently of the core. Next we explain how this layer is structured.
How the work proceeds: terminal implementation stages
We build the implementation route so that every decision is verified before it enters the product. First, we analyze the current scheme: where quotes come from, how the order book is assembled, where trade history is stored, and what limits exist on the venue side. This shows what we migrate as is and what we rewrite for real load.
-
Scheme audit. We map data flows and failure points: price sources, order book aggregation, authorization, and the order sending channel. The output is a list of bottlenecks with a note on which ones will break during the first volatility spike.
-
Design. We lock down the architecture: separation of the quote stream and trading commands, reconnection rules, and behavior during a connection break.
Separately, we define what the trader sees if there is no data for several seconds — the last known order book or an explicit “no connection” status.
-
Assembly and configuration. We implement charts, the order book, portfolio, and order forms, and configure parameters for specific markets: history depth, update frequency, and limits on the number of active connections.
-
Load testing. We run the terminal on a recording of a real stream and on a synthetic peak: hundreds of instruments simultaneously, order book update spikes, and forced disconnections. We look not at average response, but at behavior during the worst seconds.
-
Acceptance. We check against the agreed list: correctness of calculations, data matching the venue, recovery after a disconnection, and processing of partial fills and rejections. We resolve discrepancies before handover.
-
Handover and training. We deliver the source code, deployment scheme, configuration description, and update regulations; we train the team and remain available for support.
Each stage ends with a verifiable artifact: a flow map, a scheme, a test run report, an acceptance protocol.
Project artifacts: configurations, schemes, regulations
After delivery, the client retains not only a working terminal, but also a set of documents by which the support team can develop it without the original code authors. We transfer artifacts to the client's repository and define who is responsible for what.
- Configuration descriptions — which parameters are set for the test and production environments: data stream addresses, request limits, reconnection timeouts; what can be changed without editing code.
- Integration schemes — how the terminal receives quotes and the order book, where public and private streams run, and how history and real-time data are separated.
- Access policies — user and administrator roles, rights to send trading orders, operation confirmation, action logging, and rules for handling keys.
- Support regulations — the procedure for updating the instrument list, actions when the order book diverges from the exchange or a connection breaks, and maintenance windows.
- Incident instructions — typical failures (data stream lost, charts lagging, order not going through), their signs, response procedure, and escalation timelines.
- Deployment documentation — build, environments, procedure for rolling out a new version and rolling back to the previous one while preserving user settings.
- Dependency map — external services and libraries with a note on what is critical for terminal operation and what can be replaced without rewriting modules.
Case study: order book and charts without desynchronization under load
What it was like before
The exchange terminal was assembled from three independent streams: candles, the order book, and the trade tape arrived separately and at different rates.
In a calm market, the desynchronization was not obvious, but during a peak — a severalfold increase in the number of connections and a spike in updates after large trades — the picture fell apart: the chart showed a price that was no longer in the order book, and the volumes in the lower panel did not match the upper rows.
Analyzing each such incident took hours: logs had to be collected from different nodes and the lagging stream identified.
What was changed and what was measured at acceptance
Updates were moved to a single ordered stream over WebSocket: each packet has a monotonic number, so when the connection breaks, the client requests only the missed range instead of rebuilding the entire state.
The order book and charts are built from a single state snapshot, so data desynchronization becomes structurally impossible rather than “unlikely.” We also limited the redraw frequency separately: the interface updates in frames, not on every event — during a spike of tens of thousands of messages, the browser stopped choking.
The load profile at acceptance replicated the real one: calm market, spike, connection break, and recovery.
Metrics before and after: state recovery — seconds versus fractions of a second, updates lost during a break — a few percent versus zero, and support requests complaining about “incorrect data” decreased by a multiple.
What to do if the terminal already runs on a ready-made solution
Yes, but it almost never happens with a single switch. The usual path is gradual layer replacement: first the data and market stream layer is migrated, then trading actions, and only then the client part.
Trading continues as usual, and the previous interface remains operational until the new one proves itself under real load.
The trade history question is resolved first — whether rollback is possible depends on it.
The production order and execution log is moved to a separate storage with continuous replication, both terminal versions work with it through a shared access layer, and each order receives an end-to-end identifier.
Then the new log can be reconciled with the old one and with exchange exports without stopping trading.
Next, routing is configured so that some accounts, instruments, or user groups work through the new terminal, while the rest use the previous one.
Quotes go over a persistent connection, the order book is assembled from a snapshot and deltas, and after a connection break the picture is restored without losing already placed orders. Rollback in this scheme is switching the route back, not deploying a backup.
Acceptance is based on discrepancies, not impressions: reconciliation of trade history across the full depth, completeness of order book recovery after a break, behavior during partial fills and order cancellations, and open position volume in both versions at once.
The previous terminal is decommissioned only when there are no discrepancies. The timeline for such a transition depends on the number of integrations and on how tightly the trading logic was embedded in the old interface.
Technical questions most frequently asked
Engineering doubts are usually not about the interface, but about data: where quotes and the order book come from, what to do if a provider fails, and what remains with your team after handover. Below are the things most often asked before the start.
Where does the terminal get quotes and the order book?
We connect at least two independent sources: the primary exchange channel and a backup aggregator. We normalize formats to a single schema, so the chart and order book logic does not depend on who sent the data. If a broker gateway is needed, we add an adapter; the rest of the code does not change.
What happens if the data provider fails?
A connection break is treated as a normal situation: reconnection with increasing delay, a buffer of recent trades, and a delay marker directly in the order book so that an order does not go out at an outdated price. A price discrepancy between sources above the threshold blocks order placement on the server side.
Can the web terminal be moved to your own servers?
Yes, deployment is designed for your environment: containers, database schema, environment variables, and the update procedure are transferred along with the code. Third-party component licenses are listed separately, and no calls to our services remain in production mode.
What does support include after handover?
Support during the first weeks, warranty fixes, and updates when source formats change — they change more often than one would like. After that, support is provided under a separate agreement with a specified response time; training for your team is included in the handover.
Let's discuss the task: what we need from you at the start
The accuracy of the initial data directly determines the estimate and work plan: from them we determine the composition of the terminal layers — connections to venues, order book assembly, chart rendering, history storage, and access separation.
The more specifically you describe data sources, load, and trading modes, the fewer clarification iterations and the more accurate the stage timelines.
- Exchanges and markets: spot, derivatives, one venue or several simultaneously — this determines the connection layer and bringing different formats to a single data model.
- Instruments and order book depth: how many price levels to show, how many pairs in one window, and how many charts a user has open at the same time.
- Data updates: order book snapshot plus deltas or full rebuild, acceptable display delay, and behavior when some updates are missed.
- History: candles and trade tape from the venue stream or from your own archive, required storage depth, and access frequency.
- Access and rights: read-only or order placement and cancellation, user roles, action log, and key storage on the server side.
- Load profile: number of concurrent sessions, reconnection when the channel breaks, and rebuilding the order book without “holes” in the data.
- Technical constraints: target browsers, corporate network, deployment in the cloud or in the client's closed environment.
- What already exists: prototype, mockups, a working terminal and its bottlenecks — this removes part of the design stages.
Describe the task in free form — that is enough for us to come back with an estimate and plan. We will break the work into stages, fix the timeline for each and the acceptance procedure, and gather any missing inputs at the first meeting.