2026-03-22 Engineering

Signal Engine to nie cron. Pisemy dlaczego.

Większość "silników compliance" to cron który raz dziennie sprawdza checklistę. Nasz nie jest cronem. Pisemy dlaczego.

No i. Konkurencja ma “silnik compliance”. Zaglądasz pod maskę ; cron co 24h, listę warunków SQL, wysłanie maila. To nie jest silnik. To rdza.

TL;DR

Cron = batch o 3 nad ranem; sygnał przychodzi 23h za późno
Event-driven na każdą mutację kosztuje za drogo (1000 sygnałów/sec)
Nasze rozwiązanie: signal scheduler z reactive deps na poziomie modeli + cron fallback
Median latency: 14 sekund; max: 4 minuty

Problem ; cron nie wystarcza

Kontekst: klient zgłasza incydent o 10:00. Powinien dostać sygnał NIS2-001 (incydent >24h bez powiadomienia) o 10:00 następnego dnia, jako wczesny ostrzegacz. Cron co 24h o 03:00 ; sygnał przychodzi 5 godzin za późno. Jak to się skończyło ; pominiętym deadline, karą administracyjną, klient szukał innego dostawcy.

Decyzja ; signal scheduler oparty na zdarzeniach + interval per typ

Każdy typ sygnału ma własny interval (tickRate). Niektóre są reactive (na każdą mutację), niektóre są cron (raz na godzinę). DPIA-MISSING leci reactive bo zmienia się przy każdym update RcpEntry. ASV-EXPIRED leci raz dziennie bo data ostatniego skanu rzadko się zmienia.

Decyzja: per-signal-type configuration. Reactive lub cron, nie obie naraz. Configurowane w kodzie, nie w bazie ; bo zmiana wymaga code review.

Rozwiązanie ; dwie ścieżki

Reactive path

Każda mutacja na RcpEntry / Supplier / Contract / Incident przepuszczana przez middleware który publikuje event do BullMQ. Worker odbiera, pyta scheduler “którę typy sygnałów reaguje na ten event”, odpala check’i. Wynik trafia do tabeli Signal.

Cron path

Dla typów które nie mają natural triggera (np. “umowa wygasa za 90 dni”) leci raz dziennie o 04:00. Dla “ASV scan przeterminowany” ; raz w tygodniu w niedzielę.

Pułapki które złapaliśmy

Pułapka 1: recursion. Sygnał generuje notification, notification generuje audit log, audit log generuje signal "audit log entry". Loop. Naprawa: scheduler ma blacklistę encji od których nie ciągniemy back-events.

Pułapka 2: bulk import zabija system. Klient importuje 4000 RcpEntry naraz. 4000 events. Worker wybucha. Naprawa: bulk-aware emitter który grupuje N events w jeden batch-event, scheduler przetwarza batch'em.

Awaria: raz BullMQ stracił 80 jobów po Redis restart. Klient przegapił sygnał o transferze poza EOG. Naprawa: każdy enqueued job loguje się w PostgreSQL przed enqueue, recovery job przy starcie scheduluje to co Redis stracił.

Liczby

Median latency w produkcji: 14 sekund od mutacji do zapisu Signal. P99: 4 minuty (gdy worker jest za busy). Cron-only fallback: 1h. To wystarcza dla 22 typów sygnałów które obsługujemy obecnie.

Pisał ktoś z zespołu RealSec. Jak chcesz pogadać o tym konkretnie ; napisz do nas.

← Wszystkie notatki