Case study: spread-monitor

Hlavní pointa: přehled, který běží sám. Když se data zastaví, nechci to zjistit až pozdě — a nechci to ručně opravovat.

Kontext

• data se sbírají u TWS (lokálně), protože to je “zdroj pravdy”
• web dashboard má být veřejný a rychlý na otevření

Design rozhodnutí (a proč)

• Collector lokálně: minimalizuje latenci a závislosti (TWS běží u mě)
• Dual‑DB režim: lokální SQLite pro dev, Postgres na Railway pro prod
• CSV záloha: jednoduchý způsob syncu dat mezi počítači
• Auth na ingest: X‑API‑Key, aby ingest nebyl veřejná díra

Největší pasti

• collector může “zamrznout” bez pádu → řešení: watchdog (ticho = exception)
• časové zóny v datech → řešení: jednotný předpoklad a nedělat JS posuny
• produkce vs lokál se často liší → řešení: autodetekce DB a stejné endpointy

Důkazy / provozní signály

• logy pro START/STOP/CONNECTED/DISCONNECTED
• dashboard: aktuál + 24h graf + průměry (rychlý sanity check)

Co bych udělal jinak

• jednoduché “health” metriky (poslední ingest timestamp + alert při zpoždění)
• export pro “postmortem”: stáhnout konkrétní okno dat + konfiguraci