# Sviluppo di sistemi real-time e distribuiti (Elixir, OTP, Phoenix)

> Sviluppatore Elixir freelance per sistemi distribuiti: pipeline ad alto throughput, backpressure, rate limiting, job con Oban, Phoenix LiveView e Kubernetes.

URL: https://fedme.dev/it/services/realtime-systems
Fornito da: Federico Meini (federico.meini@gmail.com)

## Pipeline che sotto carico si piegano invece di spezzarsi.

Costruisco backend real-time ad alto throughput in Elixir e OTP: motori di invio che spingono milioni di messaggi, sistemi di job che non perdono mai lavoro e interfacce live che si aggiornano mentre le cose accadono.

## Cosa ottieni

- Un throughput che puoi prevedere e spiegare, con backpressure, code limitate e rate limit progettati fin dall’inizio invece che aggiunti in un secondo momento.
- Lavoro in background affidabile (retry, schedulazione, unicità, code con rate limit) con Oban.
- Interfacce live e collaborative con Phoenix LiveView e PubSub.
- Un’osservabilità che spiega gli incidenti: telemetria, metriche Prometheus, dashboard Grafana, alert utili.

## Quando “in staging funzionava” non basta

I sistemi real-time raramente cedono al carico medio. Cedono quando parte una campagna e diecimila persone rispondono nello stesso minuto, quando un’API a valle inizia a fare throttling, o quando una tempesta di retry raddoppia un traffico che già facevi fatica a reggere.

In Turn.io ho costruito il **motore di invio massivo** usato per campagne nazionali di salute pubblica, tra cui una che ha raggiunto 14,7 milioni di persone, e per i promemoria delle campagne vaccinali nazionali. Combina rate limiting, backpressure, tracciamento delle consegne e retry. Ho costruito anche l’**infrastruttura di job e pipeline dati su Oban Pro** e un **sistema di trigger in stile IFTTT con un motore di regole**, tutto in Elixir e Phoenix su Google Cloud e Kubernetes.

## Cosa costruisco

**Pipeline ad alto throughput.** Stadi guidati dalla domanda (GenStage, Broadway) in cui sono i consumer a prelevare il lavoro, le code restano limitate e il throughput si assesta su quello che la dipendenza più lenta consente.

**Rate limiting e retry fatti bene.** Token bucket per mittente o per tenant, retry con backoff esponenziale e jitter, chiavi di idempotenza perché un retry non invii mai due volte lo stesso messaggio.

**Sistemi di job affidabili.** Oban per il lavoro che non si può perdere: invii programmati, webhook verso terze parti, esportazioni di dati, automazioni in stile cron, con unicità e rate limit per coda.

**Motori di regole e trigger.** Automazioni guidate dagli eventi (“quando succede X e Y è vero, fai Z”) che anche chi non è un ingegnere può configurare in sicurezza.

**Interfacce live.** Phoenix LiveView e PubSub per dashboard e inbox che si aggiornano in tempo reale senza bisogno di un team frontend separato.

## Come lavoro

1. **Modellare il carico.** Medie, picchi, raffiche e i rate limit che non controlli.
2. **Rendere limitata ogni coda e guidato dalla domanda ogni stadio.** Decidere in anticipo cosa succede in caso di sovraccarico: rallentare, scartare o rimandare.
3. **Strumentare prima di ottimizzare.** Eventi di telemetria su ogni stadio, così vedi dove va a finire il tempo.
4. **Fare load test con forme di traffico realistiche,** comprese le modalità di guasto.

## Servizi correlati

- [Sviluppo WhatsApp Business Platform](https://fedme.dev/it/services/whatsapp-business-platform)
- [PostgreSQL ed Elasticsearch su larga scala](https://fedme.dev/it/services/postgres-elasticsearch): dove finiscono tutti quei messaggi.

## Come possiamo collaborare

- **Revisione della scalabilità**: Da una a due settimane di profilazione del sistema sotto carico, per trovare i veri colli di bottiglia e scrivere un piano con le priorità.
- **Sviluppo**: Progettazione e sviluppo end-to-end di una pipeline, di un sistema di job o di una funzionalità real-time, con load test prima del lancio.
- **Senior engineer nel tuo team**: Part-time nel tuo team per guidare un progetto di scalabilità e far crescere il team su OTP.

## Stack

Elixir, Erlang/OTP, Phoenix & LiveView, GenStage / Broadway, Oban Pro, PostgreSQL, Google Cloud, Kubernetes, Prometheus & Grafana

## FAQ

### Perché Elixir per i sistemi real-time?

La BEAM ti dà milioni di processi leggeri e isolati, alberi di supervisione che riavviano ciò che si rompe e uno scambio di messaggi che si sposa in modo naturale con i carichi di messaggistica. Rispetto alla maggior parte dei runtime, rende molto più facile gestire bene l’ordinamento per utente, la backpressure e il degrado controllato.

### Cos’è la backpressure e perché è importante?

Backpressure significa che gli stadi a valle comunicano a quelli a monte quanto lavoro possono accettare. Senza, un picco di traffico riempie memoria e code finché qualcosa non cede. Con la backpressure, il sistema rallenta in modo controllato e si riprende da solo.

### Lavori anche su sistemi non scritti in Elixir?

Sì. I concetti si trasferiscono (code limitate, domanda, idempotenza, rate limiting) e scrivo anche Python e TypeScript. Detto questo, è in Elixir che rendo di più.

### Fai load test?

Sì. Faccio load test prima del lancio e riproduco traffico con la stessa forma di quello di produzione, compresi picchi improvvisi, API a valle lente e retry, perché è lì che arrivano le sorprese.

## Contatti

Email federico.meini@gmail.com · https://fedme.dev/it/contact