Real-time competitive intelligence dla fintech tradingowego

§01Wyzwanie

Fintech klient (Series B, trading platforma dla retail crypto+forex traders) konkurował na fundamentalnej metryce: szybkość z jaką ich UI pokazuje aktualne pricing data z konkurencyjnych venues. Ich research wykazał, że traderzy decydujący o kupnie/sprzedaży patrzą na 3-4 platformy jednocześnie — kto pokazuje pricing pierwszy, ten zatrzymuje user attention.

Stan w 2024: ich pipeline scrape'owy używał Selenium + datacenter proxies, refresh co 5-10 minut, success rate <75% z powodu blocków na Cloudflare-protected venues. Real lead time vs największych konkurentów był 4-6 minutes BEHIND. Każda minuta delay = mierzalna utrata user retention.

Wewnętrzny zespół próbował upgrade dwukrotnie. Pierwsza próba (residential proxies + Playwright) zwiększyła success rate do 89% ale nie zmieniła latency — zbyt wiele synchronicznych retries. Druga próba (przepisanie na Go workers + Kafka) zwiększyła throughput ale nie rozwiązała anti-bot detection w peak hours.

§02Podejście

Zaprojektowaliśmy real-time architecture z trzema warstwami parallelism: spatial (14 venues skanowane jednocześnie), temporal (każdy venue z dedicated worker pool refreshujący co 25-30s), redundancy (każdy critical pair scraped z 3 venues z cross-validation).

Critical decisions: residential mobile proxy pool dla peak hours (gdy datacenter staje się useless), browser farm z 60-80 concurrent sessions per venue, dedicated fingerprint pool per venue (każdy venue ma własne anti-bot tuning), real-time event stream do klienta przez Kafka.

Architektonicznie: Temporal jako orchestrator (continuous workflows, nie batch), Playwright pool w Kubernetes z autoscaling na latency metric, ClickHouse dla time-series price storage, custom WebSocket gateway dla real-time delivery do client UI. Persistance double-buffered — primary path do Redis (sub-millisecond reads), secondary do Postgres dla historical analytics.

Anti-detection: persona engineering per venue — każdy worker ma stable identity (browser fingerprint, IP geography, user agent, cookies) zachowywaną przez 6-12 godzin. Rotation tylko gdy CAPTCHA rate przekracza threshold. Behavioral simulation per venue tunowana do typowych user patterns na danej platformie.

§03Wynik

Pricing lead time vs największych konkurentów: -7 minut average (czyli klient widzi pricing 7 minut wcześniej niż konkurenci). Zmierzone przez third-party benchmarking service przez okres 6 miesięcy.

Success rate aggregated across 14 venues: 97.8% (vs 75% baseline). P95 latency end-to-end (od venue source do client UI): 1.8 sekundy.

User retention metric (return-within-7-days dla active traders): +28% post-deployment. Client attributes to lead time advantage based na controlled rollout.

System operating 18 miesięcy 24/7 z 99.7% uptime. Dwie major outages w tym okresie — obie odzyskane w <30 min thanks to multi-venue redundancy (jeśli venue X padł, cross-validation z 2 innych pokrywa luki).

Stack

Wskaźniki

• 800+ — Trading pairs monitorowane
• 14 — Venues
• 25-30s — Refresh interval
• 97.8% — Success rate
• 1.8s — P95 latency end-to-end
• 99.7% — Uptime
• +28% — User retention lift