# ArhitecturăPlatformă decizională event-driven, multi-tenant, augmentată ML — cum este structurată.

## 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](/ro/services/development/).