Ottimizzazione della risposta backend: code, async, backpressure

1) Perché: obiettivi e SLO

L'obiettivo è una risposta rapida stabile anche sotto i picchi. Il business esprime questo SLO:

API (CRUD/directory): p95 da 250 a 400 ms, errore rate <1%.
Pagamento/Settlent (asincrona): SLA interno per la conferma di 2-5 min, e al cliente per il momento 202/Accetted + status-poller/webhook.
WS/real-time: RTT p95 ≤ 120 мс, disconnect ≤ 0. 5%.

Chiave: disattivare i passaggi lenti (provider, database, API esterne) dalla risposta utente attraverso le code e limitare correttamente il carico di lavoro.

2) Quadro base: dove si ottiene la latitanza

Colli di bottiglia: BB (pool/indici), provider esterni (PSP/videogiochi) che bloccano I/O, GC/World stop, serializzazione JSON, aggregazioni «pesanti».

Sintomi: crescita p99, coda di connessioni a database, picchi di retrai, timeout catena (retry storm).

Antidoto: trasportatori asincroni + backpressure + timeout/retrai + idampotenza.

3) Pattern asincroni SEDA e CQRS

SEDA (staged event-driven architetture) - Suddivide l'elaborazione in fase (ingress) convalida, record, integrazione e notifica). Ognuno ha il suo turno e i limiti del parallelismo.

CQRS - Separa lettura e scrittura. Scrittura nel registro/database, lettura in proiezioni/cache.

Outbox: l'evento viene pubblicato in modo atomico con la registrazione (evitiamo i messaggi «persi»).

Saga: processi aziendali di lunga durata con transazioni compensative anziché globali.

4) Code e striping: selezione e tuning

RabbitMQ/NATS JetStream - Team di attività (work queues), Kafka - eventi/striam con replica.

Impostazioni che influiscono sulla risposta:

Prefetch/max in-flight - Limitare il numero di messaggi da gestire contemporaneamente al worker (ad esempio 16-64) per non «segnare» un database/API esterno.
Acker/ripetizioni: «ack» dopo la scrittura idpotente; ripetizioni con ritardo esponenziale e jitter.
DLQ/parcheggio lot - Non ci sono retrai senza pattuglie - dopo N, i tentativi vanno a Dead Letter Queue.
Partizionamento (Kafka) - Chiave di entità (userId/txnId) per l'ordinamento; parallelismo attraverso il numero di partenze.

5) Pressione inversa (backpressure) - come non affondare

L'idea è di prendere solo quanto si può elaborare entro la latitanza dello SLO.

Tecnici:

Limitare la concorrenza (semaphore/worker-pool) per ogni dipendenza esterna: database, PSP, provider di giochi.
Shaping del traffico: token-bucket/leaky-bucket all'ingresso del servizio e su percorsi critici.
Code con limite superiore: al momento del riempimento, taglia la coda (429/503 + Retry-After) o trasforma in asap-batch.
Adattative concertency (AIMD) - Cresce il parallelismo al successo, riducendolo durante i timeout.
Circuito Breaker: 'closed n'open n'half-open' per errore/timeout dell'API esterna; open - degrado (cache/stab).

Pseudocode (Go-simile):

go sem: = make (chan stratt {}, 64 )//limite di concorrenza per database/PSP

func handle(req) {
select {
case sem <- struct{}{}:
defer func(){ <-sem }()
ctx, cancel:= context. WithTimeout(req. ctx, 300time. Millisecond)
defer cancel()
res, err:= db. Do(ctx, req)
if err == context. DeadlineExceeded { metrics. Timeouts. Inc(); return TooSlow() }
return Ok(res)
default:
metrics. Backpressure. Inc()
return TooBusy(429, "Retry-After: 0. 2")
}
}

6) Time out, retrai e jitter: «Tre balene di sopravvivenza»

Time-out è più breve di SLO: se SLO 400 ms, timeout per database/provider 250-300 ms; timeout totale della richiesta <400-600 ms.

Retrai è limitato e intelligente: 1-2 tentativi max, solo per operazioni sicure (idipotenti), con espositore e jitter.

Coalizione: aggregare le ripetizioni per una sola chiave.

Pseudocode (esponente + jitter):

python for attempt in range(0, 2):
try:
return call(dep, timeout=0. 3)
except Timeout:
backoff = (0. 05 (2attempt)) + random. uniform(0, 0. 05)
sleep(backoff)
raise UpstreamUnavailable

7) Idampotenza e deduplicazione

Idempotency-Key su HTTP (depositi, pagamenti), 'operation _ id' in database (indice univoco).

Inbox/Outbox: webhoop in entrata - sempre attraverso una tabella inbox invariabile con dedupe a «event _ id»; in uscita da outbox per transazione.

Exactly-once «in senso»: consente la ricarica/esecuzione, ma l'effetto è uno.

8) API rapida per operazioni lente

Risposta sincrona: 201/202 + URL di stato ('/status/{ id} '), ETA e suggerimenti di retrotreno.

Webhook/Server-Sent Events/WS è un po'di state quando è pronto.

Disciplina client: «Retry-After», Idempoted, limite di sondaggio.

Esempio di risposta:

json
HTTP/1. 1 202 Accepted
Location: /v1/withdrawals/req_9f2/status
Retry-After: 2
{
"request_id": "req_9f2",  "state": "processing",  "next_check_sec": 2
}

9) Minimizzare il funzionamento a caldo

Portate le cose pesanti in fondo: trasformazioni, aggregazioni, notifiche, scrittura in DWH.

Cache e proiezioni: spesso leggibile - cache-aside con TTL breve ed eventi invalidanti.

Pattern Batch: raggruppare le chiamate esterne (ad esempio, richiedere i limiti del provider una volta in N mc).

Serializzazione: codec veloci (protobuf/msgpack) per i collegamenti tra server; La JSON è solo su edge.

10) Database sotto controllo

I pool di connessione sono i bordi superiori (basati su core/IO) e le code al pool sono attivate.

Indici e piano: p95 explain + regressione automatica dei piani.

Timeout query: brevi, 'statement _ timeout' (Postges).

Hot rows/locks - Crash a chiave, blocchi ottimistici (versione del saldo), saga invece di transazione monolitica.

11) WebSocket/real-time

Il vincolo di distribuzione è batched broadcast, max msgs/sec per connection.

Backpressure interno: coda di messaggi in uscita con gap in caso di sovraccarico - drop low-priority.

Sticky-routing e PDB nelle release - per non produrre la tempesta di reconnect.

12) Osservazione per non indovinare

Metriche (RED/USE + backpressure):

«richiest _ rate», «error _ ratio», «latency _ p95/p99» lungo i percorsi.
`queue_depth`, `lag_seconds`, `consumer_inflight`, `retries_total`, `dlq_rate`.
`backpressure_drops`, `admission_rejects`, `circuit_open`.
Для БД: `connections_in_use/max`, `locks`, `slow_queries`.
Trainer: «queue» worker «db/psp» con i tag «operation _ id», «partition», «retry».
Loghi: strutturali, con «trace _ id», senza PII; Eventi individuali «open/close route».

13) Test sotto carico

Open-model (arrivals/sec) per i picchi Closed-model (VUS) per le sessioni.

Profili: brevi burst 60-120 s e soak 1-4 h

Iniezioni di guasto: rallenta l'API esterna di + 200-500 ms, guarda i r99/retrai/code.

I criteri per la zona verde sono «queue _ lag», stabili p95, «dlq_rate≈0».

14) Sicurezza e affidabilità

Code di TLS/mTLS, firma dei messaggi, controllo dello schema (Avro/Protobuf + Schema Registry).

Idempotent producer (Kafka), exactly-once tx dove giustificato.

Modalità caos: rovina periodicamente la dipendenza e guarda al degrado (circuito, fallback).

15) Esempi di «pezzi» di configurazione

Nginx/Avvoy di input shaping:

nginx limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
server {
location /api/ {
limit_req zone=api burst=40 nodelay;
proxy_read_timeout 0. 6s; # più breve SLO proxy _ connect _ timeout 0. 2s;
}
}

RabbitMQ (prefetch):


basic. qos (prefetch _ count = 32) # saldo CPU/IO

Kafka consumer (frammento Java):

java props. put(ConsumerConfig. MAX_POLL_RECORDS_CONFIG, 200);
props. put(ConsumerConfig. FETCH_MAX_BYTES_CONFIG, 5_000_000);
props. put(ConsumerConfig. MAX_POLL_INTERVAL_MS_CONFIG, 60_000);

16) Assegno-foglio di implementazione (prod-ready)

I percorsi critici sono suddivisi in risposta sincrona e elaborazione asincrona (SEDA).
Admision control e limiti di concorrenza per dipendenze esterne.
Timeout più breve di SLO; ≤ 2, con un espositore e un jitter; Coalizione.
Circuito breaker + degrado (cache/stab), criterio half-open.
Code/striam: prefetch/in-flight, DLQ, partiture di chiavi.
Idempotenza (operation _ id/Idempotency-Key), Outbox/Inbox, deduplicazione.
Cache: cache-aside, TTL breve + evento invalidante.
Database: limiti dei pool, statement _ timeout, indici, strategie anti-lock.
WS: limiti dei messaggi, battitura, sticky-routing, PDB.
Osservabilità: metriche backpressure/queues/retries, trailer end-to-end, dashboard.
Test di carico e guasto (open + closed, burst + soak), criteri per l'area verde.

Curriculum

Backend veloce non è «fare un'altra cache», ma un flusso controllato: ingresso limitato, pesante in fondo, ogni fase con code e limiti, retrai rari e intelligenti, e catene protette da circuito breaker e idompotenza. Aggiungi la disciplina dei timeout, l'osservabilità e gli stress test regolari - e il vostro p95/p99 rimarrà verde anche sotto i bursti e i capricci dei provider esterni.