Arhitectură

Privire de ansamblu a pipeline-ului#

Stream ingest → validatori de feature → persistență
                                        ↓
                                  Event bus (PG LISTEN/NOTIFY)
                                        ↓
                            ┌──────────────────┐
                            │ Decision daemon  │ (config per tenant)
                            └────────┬─────────┘
                                     ↓
                              Acțiune validată
                                     ↓
                              Outcome feedback
                                     ↓
                            Training de model / tuning

Platforma transformă fluxuri brute de date printr-un pipeline deliberat etajat în decizii convergente. Fiecare etapă are o singură responsabilitate și emite durable events pentru următoarea.

Nucleu event-driven#

• Event bus. PostgreSQL LISTEN/NOTIFY transportă evenimente între daemoni. Evenimentele sunt persistate într-un tabel durable, nu doar broadcastate — consumatorii pot replay-a după reconectare de la un cursor.
• Livrare at-least-once. Consumatorii confirmă evenimentele procesate. Evenimentele neconfirmate sunt livrate din nou după timeout. Idempotența este responsabilitatea consumatorului.
• Replay cursor-tracked. Fiecare consumator își ține propriul cursor. După o fază de deconectare, continuă unde a rămas — nu se pierd evenimente, niciuna nu este procesată duplicat dincolo de semantica de retry configurată.

Pipeline ML#

• Modele. XGBoost antrenat pe feature-uri istorice, cu ONNX Runtime pentru inferență (2–5× mai rapid decât framework-ul de training).
• Outputs. Modelele clasifică regimuri pe trei dimensiuni — direcție, volatilitate, calitate. Fără predicții punctuale speculative.
• Tuning de hiperparametri. Optuna cu walk-forward holdout, valuri champion/challenger, gates de calitate.
• Buclă de feedback. Outcome-ul fiecărei decizii este logat și reintrodus în următoarea rundă de tuning.

Model multi-tenant#

Izolarea tenanților este aplicată pe două niveluri:

• Stored procedures. Toate operațiile pe partea tenantului trec prin stored procedures care impun ownership. Scrieri directe în tabele de către codul tenantului nu sunt permise.
• Row-level security. Postgres RLS ca backstop dur. Chiar dacă logica de aplicație are un bug, RLS împiedică accesul cross-tenant la date.

Configurația per tenant include:

• Chei și rate limits.
• Kill switch. Override de operator pentru a dezactiva instantaneu un tenant fără redeploy.
• Profil de risc. Parametri de prag per clasă de decizie.

Validatori#

Trei locuri unde se face validare:

1. Înainte de persistență. Evenimentele de stream care nu trec validarea sunt marcate, nu droppate tăcut. Operatorii le văd pe dashboard.
2. Înainte de training-ul modelului. Feature-urile pentru training sunt revalidate împotriva schemei. Drift-ul declanșează o alertă înainte ca modelele să fie reantrenate.
3. La runtime. Validatorii de feature rulează continuu cu auto-recovery DATAMISSING — când lipsește un feature așteptat, daemonul cade pe un default documentat și emite un eveniment structurat.

Observability#

• 21 de dashboarduri live. Heartbeat, latență, detecție de drift, distribuție de decizii, volum per tenant.
• Logging structurat. Consolă, fișier și bază de date — aceleași evenimente de log din toate trei lizibile prin același query.
• Health monitoring. Fiecare daemon emite evenimente de sănătate într-o cadență fixă. Evenimente lipsă declanșează pages.

Mecanisme de gradul producție#

• Circuit breakere per sursă de date — căderile degradează grațios în loc să se propage în cascadă.
• Alerting prin e-mail și XMPP pentru evenimente relevante operatorului.
• Default-uri universale config-driven. Maparea surselor de date, lanțurile de fallback, conversiile de unități, pragurile — toate în JSON. Fără magic numbers în cod.
• Izolare de proces prin tmux + Devuan — daemonii pot fi restartați individual fără coordonare.

Ce nu este#

• Nu este o platformă de autoscaling tip Kubernetes. Asta rulează pe un număr mic de mașini bine înțelese, cu plasare deliberată a daemonilor.
• Nu este o soluție „pune și uită". Seturile de token-uri, versiunile de model, configurațiile de tenant și dashboard-urile au nevoie de atenție din partea operatorului.
• Nu este generică. Platforma reflectă o clasă specifică de probleme decizionale de înaltă frecvență — adaptarea la un workload foarte diferit este serviciul de Dezvoltare.