Design Crypto Price Alerts - System Design | WinJob

Problem Statement: Crypto Price & Whale Alerts

Design a crypto price and whale alert platform like CoinGecko alerts, Whale Alert, and Nansen signals: users define durable rules on spot prices and large on-chain movements, then receive push, email, webhook, or Telegram notifications within strict latency budgets. This section covers problem statement: crypto price & whale alerts during the understanding phase.

Operational detail

Anchor capacity: 2M DAU alert users, 48M active rules, 8k tracked assets, 14k price ticks/s ingest, 420k rule eval/s peak, 55k notify/s peak, price alert p99 ≤25s, whale alert p99 ≤90s. Track eval_lag_ms, price_age_ms, and notify_success_rate on every dashboard panel.

Failure and edge cases

Oracle flash wicks, exchange API stalls, Kafka consumer rebalance duplicates, whale label false positives, push token rot, and partner webhook retry storms.

Depth notes

Mechanism slice: Retail traders set BTC/ETH threshold and percent-move alerts drives shard sizing and cooldown TTL choices.
Operational drill: when Whale watchers subscribe to large on-chain transfers by USD notional degrades, show metric thresholds and user-visible stale banners.
Staff+ extension: document asset-level circuit breakers tied to multi-source median disagreement.
Interview checkpoint (sec-01-understanding): quantify CoinGecko-scale price aggregation feeds rule evaluation with arithmetic, not adjectives.
Threat tie-in: alert fatigue from duplicate firings erodes retention faster than occasional false negatives.
Trade-off hook: managed chain indexers vs self-hosted nodes—state cost and label freshness honestly.

Invariants

Dedup invariant: one user-visible firing per (rule_id, 5s bucket) regardless of eval retries.
Price invariant: store usd_micros integers; never compare floats on tick streams.
Separation invariant: whale ChainEvent path must not block price tick eval hot shards.

Extended narrative

Users author durable AlertRule rows; a streaming evaluator compares incoming PriceTick and ChainEvent facts against each rule, emitting AlertFiring records idempotently into channel-specific outboxes. During volatility, evaluators batch ticks every 500ms so rule comparisons amortize over hundreds of rules per asset; notify orchestrator coalesces same-asset firings per user when cooldown allows, cutting provider egress without hiding materially different rule types.

Case study tie-in

CoinGecko scales retail alerts on aggregated CEX medians; Whale Alert specializes in labeled large transfers; Nansen layers wallet intelligence for fund and exchange tags. A coherent design cites all three without conflating their data planes.

javaOne Dark Pro

1 public record FiringId(long ruleId, long bucketEpochSec, int conditionVersion) {
2   public String dedupKey() { return ruleId + ":" + bucketEpochSec + ":" + conditionVersion; }
3 }

pythonOne Dark Pro

1 def should_fire(last_fired_ts: float | None, cooldown_sec: int, now: float) -> bool:
2     if last_fired_ts is None:
3         return True
4     return (now - last_fired_ts) >= cooldown_sec

typescriptOne Dark Pro

1 export interface PriceTick { assetId: string; usdMicros: bigint; observedAt: string }

Why interviewers care

Crypto Price Alerts interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Crypto Price & Whale Alerts that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Retail traders set BTC/ETH threshold and percent-move alerts
•Whale watchers subscribe to large on-chain transfers by USD notional
•CoinGecko-scale price aggregation feeds rule evaluation
•Delivery spans mobile push, email, webhook, and Telegram bots

1	public record FiringId(long ruleId, long bucketEpochSec, int conditionVersion) {
2	public String dedupKey() { return ruleId + ":" + bucketEpochSec + ":" + conditionVersion; }
3	}

1	def should_fire(last_fired_ts: float \| None, cooldown_sec: int, now: float) -> bool:
2	if last_fired_ts is None:
3	return True
4	return (now - last_fired_ts) >= cooldown_sec