Quando appoggi la carta alla cassa, in mezzo secondo scarso qualcosa deve decidere se quell’addebito assomiglia a te o a chi ti ha rubato il numero in un data breach sei mesi fa. Databricks racconta come costruire quel “qualcosa” con una app di esempio (backend FastAPI, frontend React, deployata come Databricks App) che fa scoring delle transazioni per frode in tempo reale, mettendo insieme due capacità della piattaforma: Model Serving con route optimization e Lakebase, il Postgres gestito per i dati di profilo e le feature che il modello legge al momento della predizione.
Il percorso di una transazione
Per ogni pagamento girano in sequenza due controlli: prima il modello assegna un punteggio, poi l’app verifica le regole di profilo (tetto di spesa giornaliero, transazioni internazionali abilitate, paese di residenza). Ciascuno dei due può rifiutare la transazione, e le regole di business possono ribaltare un’approvazione del modello: un pagamento che il modello ritiene lecito viene comunque bloccato se supera il tetto giornaliero impostato dall’utente. Il modello gestisce il rischio statistico, il profilo gestisce le preferenze.
Route optimization e Lakebase
Tra applicazione e container di inference c’è un hop di rete: per un batch è irrilevante, per un checkout è tutto. La route optimization accorcia quel percorso, sbloccando più QPS e latenze più stabili, e si interroga tramite il flusso data-plane con OAuth. Il modello (un pyfunc MLflow con CatBoost) fa il proprio lookup su Lakebase usando le prime sei cifre della carta (il BIN) come chiave, per recuperare feature storiche come l’importo medio e il tasso di chargeback. La stessa tabella customer_features serve due lettori: il container del modello per le feature e il backend per i campi di profilo. Un dettaglio operativo importante: entrambi mantengono un connection pool con rotazione del token OAuth, così la maggior parte delle richieste evita l’handshake TLS. Lakebase, inoltre, autoscala (con scale-to-zero) per assorbire i picchi senza pagare capacità di picco alle 3 di notte.
I numeri
Su 5.000 richieste sequenziali verso l’endpoint route-optimized, la latenza end-to-end è stata di 27 ms al p50 e 37 ms al p95. Il lookup delle feature su Lakebase è rimasto a una cifra al p50 (8,9 ms) e sotto i 14 ms al p95. L’inference vera e propria è quasi gratis: la predizione CatBoost su un vettore di 12 feature costa 0,4 ms alla mediana. L’overhead di rete è di circa 17 ms, con uno spread p50-p95 di soli 4 ms. Tutto ben dentro il budget di latenza di un checkout.
- Casi real-time sotto i 50 ms come fraud scoring, personalizzazione e dynamic pricing si possono costruire nativamente su Databricks.
- La route optimization tiene l’inference e il feature lookup sulla stessa piattaforma governata, con overhead di rete contenuto e stabile.
- Connection pooling con rotazione OAuth e autoscaling di Lakebase sono i pattern che tengono la latenza stabile sotto carico.
Fonte: What happens in the milliseconds after you tap pay — https://www.databricks.com/blog/what-happens-milliseconds-after-you-tap-pay
Hai qualcosa da aggiungere? Unisciti alla discussione.