Pronix Information Technologies
Docs

Architektura

Przegląd pipeline’u

Stream-Ingest → walidatory feature → persystencja
                                        ↓
                                  Event-Bus (PG LISTEN/NOTIFY)
                                        ↓
                            ┌──────────────────┐
                            │ Decision-Daemon  │ (konfig per tenant)
                            └────────┬─────────┘
                                     ↓
                            zwalidowana akcja
                                     ↓
                            outcome-feedback
                                     ↓
                          trening modelu / tuning

Platforma przekształca surowe strumienie danych przez celowo wielostopniowy pipeline w zbieżne decyzje. Każdy stopień ma jedną odpowiedzialność i emituje durable events dla następnego.

Sterowany zdarzeniami rdzeń

  • Event-Bus. PostgreSQL LISTEN/NOTIFY transportuje eventy między daemonami. Eventy są persystowane w durable tabeli, nie tylko broadcastowane — konsumenci mogą po reconnectcie replayować od cursora.
  • At-least-once-delivery. Konsumenci potwierdzają przetworzone eventy. Niepotwierdzone eventy są po timeout dostarczane ponownie. Idempotencja jest odpowiedzialnością konsumenta.
  • Cursor-tracked replay. Każdy konsument trzyma własny cursor. Po fazie disconnect kontynuuje tam, gdzie skończył — żadne eventy nie giną, żadne nie są przetwarzane podwójnie poza skonfigurowane retry-semantyki.

Pipeline ML

  • Modele. XGBoost trenowany na historycznych feature’ach, z ONNX Runtime do inferencji (2–5× szybciej niż framework treningowy).
  • Outputy. Modele klasyfikują reżimy w trzech wymiarach — kierunek, zmienność, jakość. Bez spekulatywnych predykcji punktowych.
  • Tuning hiperparametrów. Optuna z walk-forward-holdout, falami champion/challenger, bramkami jakości.
  • Pętla feedback. Outcome każdej decyzji jest logowany i wpuszczany z powrotem do następnej rundy tuningowej.

Model multi-tenant

Izolacja tenantów jest wymuszana na dwóch poziomach:

  • Stored procedures. Wszystkie operacje strony tenanta idą przez stored procedures, które wymuszają ownership. Bezpośrednie zapisy do tabel przez kod tenanta nie są dozwolone.
  • Row-level security. Postgres-RLS jako twardy backstop. Nawet gdy logika aplikacji ma bug, RLS zapobiega cross-tenant data-access.

Konfiguracja per tenant obejmuje:

  • Klucze i rate-limits.
  • Kill-switch. Override operatora, aby natychmiastowo zdeaktywować tenant bez redeploy.
  • Profil ryzyka. Parametry progowe per klasa decyzji.

Walidatory

Trzy miejsca, w których odbywa się walidacja:

  1. Przed persystencją. Eventy streamu, które nie przechodzą walidacji, są markowane, nie cicho dropowane. Operatorzy widzą je na dashboardzie.
  2. Przed treningiem modelu. Feature’y do treningu są ponownie walidowane wobec schematu. Drift triggeruje alert, zanim modele zostaną przetrenowane.
  3. W runtime. Walidatory feature’ów działają ciągle z auto-recovery DATAMISSING — gdy oczekiwany feature brakuje, daemon spada do udokumentowanego defaultu i odpala strukturyzowany event.

Observability

  • 21 live-dashboardów. Heartbeat, latencja, detekcja driftu, rozkład decyzji, wolumen per tenant.
  • Strukturyzowane logowanie. Konsola, plik i baza danych — te same eventy logu z wszystkich trzech czytelne tym samym query.
  • Health-monitoring. Każdy daemon emituje eventy health w stałej kadencji. Brakujące eventy triggerują pages.

Mechanizmy gotowości produkcyjnej

  • Circuit Breaker per źródło danych — awarie degradują się gracefully, zamiast kaskadować.
  • Alertowanie e-mail i XMPP dla eventów istotnych dla operatora.
  • Universal config-driven defaults. Mapowania źródeł danych, łańcuchy fallback, konwersje jednostek, progi — wszystko w JSON. Bez magic numbers w kodzie.
  • Izolacja procesów przez tmux + Devuan — daemony mogą być restartowane indywidualnie bez koordynacji.

Czym to nie jest

  • Bez platformy autoscalingu w stylu Kubernetes. To działa na małej liczbie dobrze rozumianych maszyn z celowym rozmieszczeniem daemonów.
  • Bez rozwiązania „postawić i zapomnieć". Zestawy tokenów, wersje modeli, konfiguracje tenantów i dashboardy potrzebują uwagi operatora.
  • Niegeneryczne. Platforma odzwierciedla konkretną klasę problemów decyzyjnych o wysokiej częstotliwości — adaptacja do bardzo innego workloadu to usługa Rozwój.
Next
Architektura