Cryptocurrency monitoring system: where rates diverge
The same pair on two venues at the same moment shows different figures.
On liquid instruments, the quote discrepancy is measured in fractions of a percent; on thin ones, it diverges by multiples, and formally both venues are right: each has its own order book and its own last trade.
While an operator manually reconciles values across web interfaces, the market moves on, and a decision is made based on a figure that no longer exists.
The reason lies in the design of market data sources.
A spot order book provides an instant but narrow picture of a single venue; an index aggregator averages several exchanges and cuts off outliers, so its value always lags; OTC and settlement quotes arrive in discrete snapshots.
The rate update delay consists of the publication interval, delivery time, and the moment when the value was recorded on the receiving side.
Then the cost of error appears: a risk control that triggers on one source stays silent on another, reporting does not reconcile between departments, and an arbitrage difference that is perfectly visible on a historical chart is unattainable in the moment.
Rate freshness is not "plus or minus a second" but an answer to the question of which point in time a specific figure is tied to.
Real-time cryptocurrency rates are not about "displaying a number" but about ensuring each value carries a label of source, time, and calculation methodology.
We break down how this is addressed: stream normalization, selection of a reference price, and rules by which a discrepancy becomes a visible signal rather than a surprise in a report.
What a real-time quote stream provides
Manual reconciliation of rates across several venues lasts exactly until the first volatility spike: prices diverge, some screens show an outdated value — and a decision is made based on it.
A single data source removes the very possibility of such divergence: the quote stream arrives in one normalized feed, where an instrument has one price and one timestamp.
What is eliminated along with manual reconciliation
The effect then becomes visible in system behavior under load, not in promises:
- Single data source — instead of a separate connection to each venue, one feed; divergence between views does not arise by design.
- Data gaps — a connection break is closed by reconnection with backfilling of the missing segment; the chart does not tear in front of the user.
- Eliminated class of failures — desynchronization between the view and the calculation module: both read one stream, not their own copies.
- Speed of reaction to the market — from a trade on a venue to an update on the screen, seconds pass instead of minutes of manual refresh.
- Peak volatility — a surge in activity does not bring down the stream: the queue is processed according to instrument priorities.
- Observability — a delay log and alerts for stream interruption separately for each instrument.
To reconcile historical series, we connect an external aggregator, for example CoinGecko, but the operational source remains the direct stream from venues: the aggregator returns data with a delay and is not suitable where a reaction to movement in the moment is needed.
Data collection options: polling, streaming, hybrid
Three ways to obtain market data differ not by "speed" but by failure profile and maintenance cost. Scheduled data collection is easy to debug: one request — one state snapshot, easy to reproduce and reconcile with history.
A streaming channel delivers changes immediately and provides lower latency, but requires keeping a connection constantly open, handling breaks, and restoring the missed interval.
| Option | When suitable | Limitations |
|---|---|---|
| Scheduled polling | Analytics, portfolio, alerts where a delay of seconds is not critical | Missing movement within the interval, source limits, increased load with frequent polling |
| Streaming channel | Order book, ticks, arbitrage, fast price alerts | Breaks and duplicate events, harder to test, history backfill needed |
| Hybrid scheme | Production with a requirement for data continuity | Two routes, source reconciliation, and a unified event model |
Hybrid collection scheme
In practice, a hybrid option is chosen: the streaming channel maintains the current price, while scheduled data collection serves as a backup route and backfills gaps after a break.
Both sources are reduced to a single event model with a timestamp and an origin marker — the calculation module does not know where the price came from.
If the stream is silent longer than the threshold, the switch goes to polling, and upon recovery it reconciles the latest values and resolves discrepancies.
Work stages: from source audit to handover
We carry out work on a cryptocurrency monitoring system in stages, and each stage is closed with a verifiable artifact: a list of sources, a scheme, a working collection loop, or a test protocol. Progress is visible in fact, and requirements can be adjusted before they turn into rework.
- Data source audit. We reconcile trading venues and aggregators by completeness of output and stability, and check discrepancies in timestamps. We record suitable sources and backups in case the primary ones fail.
- Stream scheme. The data route from ingestion to the view: where normalization happens, where aggregation happens, where history is stored, and by what rules outliers are cut off.
- Collection setup. We bring instruments, currency pairs, and timestamps to a unified form, configure trade deduplication, and restore gaps after communication breaks.
- Failure testing. We disconnect a source, introduce delay, submit an activity surge — and see whether the loop switches to backup and does not lose history.
- Load testing. We run the loop at volumes above expected and measure how update latency grows at peak and whether it recovers after the surge.
- Observability. Metrics and alerts for each source, separate monitoring of discrepancies between venues, so that price distortion does not enter the calculation unnoticed.
- Acceptance and handover. Demonstration on real data, configuration documentation, failure response regulations, and training for your team.
After handover, we remain in contact during the agreed support period — this time is spent on fine-tuning, not on new requirements.
Schemes, access policies, and regulations at the output
At project completion, the customer retains not only a working service but also a set of artifacts that can be used to develop the system in-house or hand it over to another team without reverse-engineering the code.
We record them at the end of the work and synchronize them with the actual state of the environments, not with drafts.
- Integration scheme — quote streams from sources to subscribers, switch points to the backup channel, message formats, and declared update frequency.
- Access policies and roles — a permission matrix: who adds sources, who sees service metrics, who stops calculation jobs. By default, the principle of least privilege applies.
- Failure response regulations — incident levels, alert thresholds, on-call procedures, time to switch to a backup source, and conditions for switching back.
- Solution documentation — component descriptions, responsibility boundaries between services, known limitations, and accepted trade-offs with rationale.
- Recovery instruction — a step-by-step scenario for restoring from a backup with actually measured time rather than estimated time.
- Set of checks — automated tests for quote stream interruption, price divergence between sources, and update lag.
- Change log and handover — architecture walkthrough with your team, answers to code questions, and a list of tasks consciously deferred.
The set is rebuilt with every significant change to the data stream: an outdated scheme is more dangerous than its absence, because decisions are made based on it.
Case study: rate monitoring without discrepancies at peaks
The service collected quotes from 14 sources and put them into one table. In a calm market, discrepancies were not visible, but during a sharp price movement, prices for a single instrument diverged by up to 1.2% — the user saw a rate that did not exist on the market. During surges, some polls did not have time to complete, and data simply dropped out of the stream.
We replaced periodic polling with continuously open streaming channels and added a normalization layer: bringing sources to a unified time scale, deduplicating repeated ticks, and filtering outliers by the median of neighboring windows.
Each value stores a source label and event time, so the discrepancy is now visible in the report rather than in the client interface.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Sources in the stream | 14 | 38 |
| Discrepancy at peaks | up to 1.2% | 0.05% |
| Delay from event to chart | 4–7 s | up to 1 s |
| Tick loss during a surge | 0.3% | 0.01% |
| Recovery after source failure | about 20 min | about 40 s |
Fault tolerance was addressed separately. Previously, a source failure stopped the chart until manual intervention: the on-call engineer noticed the frozen stream from a complaint.
Now switching to the backup channel takes tens of seconds, and subscription consumers are not disconnected — the service continues to deliver data to the same clients.
The outcome of the rate monitoring case is not only the stream stability figures. The validation layer compares prices between sources, flags arbitrage anomalies, and raises an alert for a persistent discrepancy.
The client sees one price with an indication of how many sources confirmed it, and this removed the main part of support requests.
How streaming differs from periodic polling
Streaming sends an event for every price change; periodic polling sends a snapshot at a fixed step. With a 30-second step, a swing within the interval is invisible, and metrics — volatility, volume spikes, threshold triggers — are calculated from a distorted series. For a rate view, this is unnoticeable; for alerts and position recalculation, it is critical.
But streaming does not cancel polling.
A persistent connection breaks during network degradation and on the source side, and a missed event can easily be mistaken for "the price did not change." Polling is idempotent: a repeated request returns the same state, and recovery after a failure does not require catching up on history.
Update frequency is not an end in itself: sources differ in granularity. Aggregators such as CoinGecko return averaged values with a delay; exchange channels return every trade.
We select the mode for the source and the task: where there is no broadcast channel, we build polling with an adaptive step for current volatility.
A separate cost item is maintenance. Streaming requires buffering, deduplication, and event ordering control; polling requires a scheduler with retries and pauses.
The hybrid covers both weak points: the stream maintains freshness, and a snapshot every few minutes reconciles the series with a reference and pulls in what was missed after a break.
Common technical questions about integration
Integration questions usually come up at the stage when quote collection is already deployed and running: you need to understand how to integrate into the existing loop without breaking it.
The calculation layer is built on top of the current collection — there is no need to rewrite working parts. Below are four concerns that we address before the start: venue failure, different source latency, rate reliability, and rights to the result.
What happens if a venue stops providing data?
Each source is isolated: a connection break does not stop the other channels. The connection is restored with increasing pause, and the rate state is held at the last confirmed value with a note about its age.
If a venue is silent longer than the specified threshold, it is excluded from the calculation — the final value continues to be calculated from live sources.
How do you calculate the rate if venues provide data with different latency?
The value is tied to the venue's own timestamp, not to the moment of receipt, so the spread of delays does not shift the picture. The calculation uses a sliding window: channels that fall outside it are not included in the result. The response shows which set of sources the rate was calculated from.
Where does confidence that the rate is reliable come from?
Each value is a consolidation of several independent venues with outlier filtering and a tolerance for divergence between them. If sources diverge more than the threshold, the value is marked as disputed rather than given as fact. Thresholds are configured for your asset profile.
Who owns the code, schemes, and documentation?
We transfer the rights to the customer: source code, stream and data schemes, configurations, documentation, and deployment regulations. The system runs in your environment and does not depend on ours — maintenance can be carried out by your own team.
What is needed to start and how we calculate the estimate
The work estimate is based on the initial data for the task, not on averaged assumptions: both the composition of the cryptocurrency monitoring system and the labor costs depend on the number of sources and requirements for quote freshness. That is why we start with a short list of what you send from your side.
- List of venues: where we take quotes from — public interfaces, aggregators, own nodes.
- Access to sources: keys, request limits, identification requirements, rate restrictions.
- Instruments and priorities: which pairs are needed, which are used for the consolidated price, which are reference.
- Freshness requirements: what delay you consider acceptable and what to do when sources diverge.
- Output points: panel, application, external subscription — who views the data and what actions they perform.
- Load and history: how many simultaneous connections you expect, for what period we store quotes.
- Failure behavior: what to show if a venue is unavailable, whether switching to a backup source is needed.
With this set, we analyze data flows between sources, storage, and client screens, identify bottlenecks, and come back with a plan and timeline estimate: what we do in the first stage, what we defer, what checks we include.
If some data is still unavailable, we record assumptions directly in the estimate. Describe the task in free form — we will clarify the rest in a conversation, and then return with the scope of work and timelines.