Alert system for traders: where signal delivery breaks
Threshold calculation is the simplest part of an alert system for traders: compare price with a level, volume with a window median, and pass the event onward. Everything breaks after that — in delivery and prioritization, when the market enters peak volatility.
When a level breaks, the load on the calculation loop grows by tens of times within seconds. The notification queue stops draining, and notification delivery latency grows to tens of seconds — the trader sees the signal when the price has already returned.
Liquidations on the venue hit separately: a cascade of forced closures pulls the price further than the risk model assumed, and all thresholds trigger simultaneously.
The second bottleneck is a storm of similar events. One impulse generates hundreds of triggers across dozens of instruments, the channel turns into a feed that is impossible to read, and the trader disables notifications entirely.
Missed signals in an alert system for traders appear more often not because of a calculation error, but because a significant event drowned among similar ones.
Data sources add their own latency: public streams of prices and liquidity metrics, including Chainlink, update at their own interval rather than instantly.
This can only be compensated for on our side — through processing order, merging similar events into one, and controlling queue length. We'll break down how this is addressed.
Effect of managed signal delivery: what changes
The most noticeable shift is the share of delivered signals. In the baseline version, a notification goes "on air" once: a channel break, app restart, or device change — and the trader learns about the trigger from history, after the move.
Managed delivery is built on delivery confirmation on the subscriber's side, retries with increasing delay, and deduplication by event key, so the same signal does not arrive twice, but is also not lost during a failure.
In practice, the delivered share rises from 80–85% to 99% and above, and on channels with unstable connectivity it is visible exactly where it breaks: the delivery metric is tracked per channel separately.
The second shift is the number of false triggers. An instantaneous price on a thin order book produces a spike that crosses the threshold but is not confirmed by either volume or depth, and the trader receives noise.
Threshold values are configured with smoothing windows and hysteresis on entry and exit, while price, volume, and liquidation triggers are checked separately and only then assembled into a single notification.
False signals become several times fewer with the same coverage of real events — the threshold stops being a trade-off between misses and noise.
The third shift is load resilience and recovery time. During a liquidation cascade, the event stream grows many times over, and ordinary "brute-force" sending starts to lag, delivering notifications with delays of tens of minutes.
Priority queues, isolation of markets from each other, and backpressure control keep delivery latency within seconds, while recovery after a failure proceeds from the last checkpoint — minutes instead of tens of minutes of manual reconciliation.
Alert delivery channels: comparison of modes
An alert is two independent decisions: where the condition is calculated and how the result reaches the trader.
The condition is either checked on a persistent connection to the trade stream, or exchange interfaces are polled on a schedule, or it is held in server-side rules — then our side evaluates the trigger, and the client's dashboard can be closed.
Delivery is a separate layer: the personal dashboard and external notifications that go out even when the person is not looking at the terminal.
Where each mode is appropriate
| Mode | When appropriate | Limitations |
|---|---|---|
| Streaming mode | Liquidations, sharp price move, volume spike | A connection per client; on disconnect, reconciliation of the missed segment is needed |
| Periodic polling | Moving averages, funding rates, open interest | Latency equals the polling step; frequent polling hits exchange limits |
| Server-side rules | Many clients, identical conditions, a single journal | Changes go through a procedure, not a click in the dashboard |
| Hybrid: rules and stream | The stream catches the event, the rule decides whether to send an alert | Debugging is harder: both the stream and the rule decision are visible |
Separation provides predictability: the stream gives low latency where it is critical, polling does not spend limits on metrics that change once a minute, and rules remove the avalanche of similar triggers through deduplication, a quiet window, and instrument priority.
Delivery is duplicated: if an external notification did not arrive, the trigger remains visible in the personal dashboard.
How we implement signal delivery: stages of engineering work
An alert is a contract between the data source and the trader: if the signal arrived, the condition was indeed met on a specific venue at a specific moment.
Therefore, the work begins with an audit of triggers, not with the interface, and ends with handing over the procedure to the on-call shift.
- Trigger audit. We collect the needed events: level breakout, volume anomaly, liquidation cascade, price divergence between venues. For each, we record the source, frequency, and acceptable latency.
- Data flow diagram. We trace the signal path from the exchange stream to delivery: normalization, deduplication, queue, priorities. We mark failure points and behavior on connection loss.
- Trigger rules. We define averaging windows, thresholds, and debouncing so that a series of duplicates on one move does not turn into noise.
- Assembly and reconciliation with the market. We run historical periods and compare what the system caught and what it missed; discrepancies are investigated down to the cause, not suppressed with thresholds.
- Load testing. We feed in peak flow — a volatile hour, mass liquidations — and check whether delivery fits within the target time and whether signals are lost.
- Escalation procedure. We describe the response to degradation: channel silence, latency growth, source failures. Each case has an owner and a response time.
- Handover to operations. We hand over documentation, dashboards, and rules for changing thresholds, and train on-call staff. After that, improvements follow the normal cycle, without constant involvement of development.
Configurations, rules, and documentation for signal delivery
After project delivery, the team has not only a working signal system but also a complete set of artifacts by which it can be developed on its own. We hand them over so that a change to a threshold or a new event type can be made without deciphering someone else's code.
- Rule configurations — price and volume thresholds, averaging windows, priorities, and duplicate suppression: one file per event type with a change history.
- Access policies — which employees can change rules and send a signal manually, which channels are available for this, and what goes into the journal.
- Flow diagram — the signal path from the market data source to the delivery channel: where the queues are, where retries happen on failure, which sections are critical for latency.
- Notification templates — message markup for each event type, variables, quiet-hours rules, and duplicate protection.
- Operations manual — system health checks, manual restart, and on-call actions when there is a discrepancy with exchange data.
- Rollback procedure — how to return the previous version of rules if a new threshold produced a surge of false triggers.
All of this resides in the customer's repository and is updated together with the code, so the team is not left with a system without documentation. Describe the task — we will come back with an estimate and a handover plan.
Case study: from an event storm to a managed signal stream
A trading signal platform collected events from several sources: price and volume came from Chainlink and exchange channels, liquidations — from its own stream.
In a calm market everything worked, but during volatility an event storm began: the same level break came from each source, liquidations arrived in batches, and within a minute a subscriber received 40-60 notifications.
The critical signal drowned in noise, traders disabled the channel — losing exactly the feature they had come for.
There were three causes: there was no duplicate suppression, notification priorities were absent — everything went in a single stream — and delivery had no per-channel budget.
The pipeline was redesigned: an event gets a key from the instrument, type, and time window; duplicates collapse into one signal with accumulated volume.
Critical liquidations go through a separate queue with guaranteed delivery and retry on channel failure, ordinary ones are aggregated into a digest, and idempotency on the recipient side prevents repeated sending.
Metrics before and after: duplicate share — from 60% to single-digit percentages, critical signal latency — from tens of seconds to one or two, delivery — from 92% to 99.9%, notification opt-outs decreased several times.
The main thing is that the class of failures "missed signal during a storm" has been eliminated: the scenario is reproduced by a load test and holds under a tenfold surge of events.
What to do if signals are already sent by an external service?
You cannot abruptly turn off an external service: while traders receive signals through it, a delay on your side means a missed entry and a blow to trust in the channel.
Therefore, a phased transition to your own alert system for traders is built as parallel operation of two loops: your own calculations run on the same market data stream, but are published to a separate channel that only a test group sees. The external service remains the primary one.
Rules are transferred not all at once, but one by one — price, volume, liquidations. Each is described declaratively: threshold, averaging window, trigger conditions. This way a rule can be run on history and compared with what the external service produced over the same period.
Discrepancies are usually explainable — a different quote source, a different window, processing latency — and they are investigated down to zero before release to the live stream.
Next comes real-time signal reconciliation: the share of matching triggers and the spread in delivery time are calculated. A case where your own loop triggered but the external one did not is investigated just as carefully as a miss. Until the numbers confirm readiness, traffic weight is not switched.
Decommissioning the third-party service is the last step: recipients are migrated in batches, and each channel retains a reverse switch for an agreed period so that you can return with one command.
The external service is shut down only after a period without discrepancies and with stable latencies — otherwise the rollback becomes an emergency one rather than a planned one.
Technical questions before project start
The technical team asks five questions at the start — and the answers largely determine the architecture: how long a signal takes to reach the recipient, what is considered an event, how the system behaves on contradictory data. We go through them before work begins so that both sides count the same thing.
What delivery latency is considered acceptable?
Latency is divided into three segments: market data ingestion, condition calculation, and delivery to the recipient. We calculate by the 95th percentile, not the average: volatile spikes are exactly what determines whether the trader makes it in time. Urgent price triggers go through a separate queue and do not wait behind bulk analytics.
How do you distinguish a liquidation from a sharp price move?
A liquidation is a forced closure of a position due to insufficient collateral, not a drawdown. Therefore, we set the trigger on a position event, not on a price level crossing.
A cascade of liquidations in one direction is separated into a separate signal: it shows pressure, not a single outlier.
What happens if sources provide contradictory data?
We reconcile price and volume between sources with a tolerance for the specific instrument. If the divergence is greater than the tolerance, the signal does not go to recipients — it is marked as disputed and written to the journal with both values. The trader does not receive a false trigger, and we see which source lagged.
How to add a new signal type?
Events are brought to a unified format: instrument, type, direction, trigger reason. A new signal is a description of the condition and message template; delivery, queue, and subscriptions do not need to be rewritten. The signal set expands without stopping those already running.
How is the system protected from duplicates?
Each event has a key: instrument, type, and time window. Repeated delivery during a failure does not create a second notification — the recipient sees one. Additionally, a debounce suppression window works so that a series of similar triggers does not turn into a stream.
Let's discuss the task and come back with a work plan
To discuss the task substantively, an input set is needed: without it, timeline estimation turns into a retelling of generalities. The more precisely the event stream and latency requirements are described, the more concrete the work plan will be.
- Market data sources: exchanges and venues from which we take prices, volumes, and liquidation data, including backups.
- Trigger logic: level breakout, volume spike, liquidation cascade, funding rate change — which conditions you consider a signal.
- Thresholds and frequency: working values, acceptable latency window from event to delivery, duplicate suppression rules.
- Delivery channels: messengers, email, external integrations, mobile notifications — and who receives each notification.
- Access and constraints: connections to sources, access modes, requirements for storing signal history.
- Acceptance criteria: how you will verify the system — on the live market, on historical data, by latency and completeness of triggers.
In response, you receive a phased work plan with timeline estimates, a diagram of data and role flows, and an agreed list of acceptance criteria. Then we fix the launch order and the points at which you accept the result.
Describe the task in free form — we will come back with an estimate and a work plan.