Passa a:
LinkedIn e Apache Kafka: 7 trilioni di messaggi al giorno

LinkedIn e Apache Kafka: 7 trilioni di messaggi al giorno

Apache Kafka, una piattaforma open-source per l’elaborazione di flussi di dati in tempo reale, è diventato uno strumento essenziale per le aziende che operano su larga scala. LinkedIn, che ha sviluppato originariamente Kafka, ne è oggi uno dei principali utilizzatori, gestendo oltre 7 trilioni di messaggi al giorno. Per sostenere questa mole di dati, LinkedIn ha creato un ecosistema Kafka su misura, affrontando sfide di scalabilità che raramente si incontrano altrove e contribuendo attivamente alla comunità open-source con le soluzioni trovate lungo il percorso.

Kafka è nato nel 2010 all’interno di LinkedIn per gestire in tempo reale i flussi di dati generati dagli utenti. Il sistema ha avuto un tale successo che è stato open-sourced nel 2011 ed è oggi uno standard industriale adottato da migliaia di aziende nel mondo. Nonostante la sua adozione diffusa, LinkedIn continua a essere uno degli utilizzatori più avanzati, con un’infrastruttura che include decine e decine di cluster Kafka, più di 4.000 broker e 7 milioni di partizioni, una scala operativa che pone sfide ingegneristiche di assoluto livello.

Kafka e il sistema di messaggistica

Per comprendere perché Kafka sia così centrale nell’infrastruttura di LinkedIn, è utile capire come funziona il sistema a un livello concettuale. Kafka è basato sull’idea del commit log distribuito: ogni messaggio prodotto da un’applicazione viene scritto in modo ordinato e immutabile su una struttura chiamata topic, suddivisa in partizioni che possono essere distribuite su più macchine. Questo design permette a molti produttori di scrivere dati in parallelo e a molti consumatori di leggerli in modo indipendente, senza che gli uni interferiscano con gli altri. I consumer group consentono a più istanze di un’applicazione di elaborare lo stesso flusso dividendosi il carico, mentre l’ordinamento all’interno di ogni singola partizione è garantito, offrendo la prevedibilità necessaria a casi d’uso come la registrazione delle attività degli utenti o la sincronizzazione tra microservizi. Il risultato è un sistema capace di gestire picchi di traffico elevati con latenze molto basse, che si presta tanto alla trasmissione di eventi in tempo reale quanto all’analisi storica dei dati archiviati nel log.

L’ecosistema Kafka di LinkedIn

I cluster Kafka di LinkedIn sono progettati per gestire miliardi di eventi al giorno, assicurando che ogni informazione venga processata in tempo reale. Le applicazioni interne si affidano a Kafka per registrare le attività degli utenti, trasmettere messaggi tra diversi servizi e raccogliere metriche di sistema, permettendo all’azienda di analizzare e ottimizzare continuamente le proprie operazioni. Per facilitare la comunicazione tra i vari componenti del sistema, LinkedIn utilizza strumenti che migliorano l’integrazione e la gestione dei dati: il REST Proxy permette anche a servizi non basati su Java di interagire con Kafka, mentre un sistema di gestione degli schemi garantisce che i dati inviati e ricevuti siano sempre coerenti. Per ottimizzare il flusso di dati tra i vari centri operativi dell’azienda, LinkedIn utilizza una tecnologia di replica che assicura disponibilità e aggiornamento delle informazioni ovunque servano, e un software interno monitora l’uso delle risorse ridistribuendo automaticamente il carico quando necessario.

Sfide e innovazioni per la scalabilità

Gestire Kafka su questa scala presenta sfide tecniche concrete che vanno ben oltre quelle affrontate dalla maggior parte delle organizzazioni. Una delle più complesse riguarda le garanzie di ordinamento: quando un flusso di eventi è distribuito su migliaia di partizioni, assicurare che messaggi correlati vengano elaborati nella sequenza corretta richiede una progettazione attenta degli schemi di partizionamento e, in alcuni casi, logiche applicative dedicate. LinkedIn ha dovuto affrontare anche il problema del rebalancing, ovvero la ridistribuzione delle partizioni tra i broker durante operazioni di manutenzione o in seguito a guasti: all’interno di cluster molto grandi, queste operazioni possono generare picchi di latenza significativi che impattano le applicazioni in produzione. Per contenere questi effetti, il team di ingegneria ha sviluppato strumenti di automazione interni in grado di pianificare il rebalancing in finestre a basso traffico e di monitorare in tempo reale lo stato di ogni partizione. Molte di queste innovazioni, come i miglioramenti alla gestione delle partizioni e i meccanismi di throttling del rebalancing, sono state successivamente contribuite alla comunità Apache, permettendo ad altre aziende di beneficiarne.

L’uso di Apache Kafka da parte di LinkedIn rappresenta un esempio di come un sistema open-source possa essere adattato e scalato per supportare operazioni globali di primissimo livello. Grazie a un ecosistema personalizzato e a una gestione attenta delle sfide operative, LinkedIn è in grado di elaborare enormi quantità di dati ogni giorno, garantendo al contempo prestazioni elevate e contribuendo alla crescita della piattaforma Kafka per l’intera comunità tecnologica.

Ranieri Vannozzi

L'autore

Ranieri Vannozzi

Sviluppatore e consulente software freelance

Scrivo codice dal 2008 e lavoro su sviluppo enterprise, architetture cloud-native e leadership tecnica. Su HeroHubs racconto quello che incontro ogni giorno nei progetti, tra codice, architetture e intelligenza artificiale.

Articolo scritto con il supporto dell'AI e rivisto dall'autore.

Post Correlati

Canary vs Blue Green: come eliminare il downtime

Architettura

Marzo 2026

Canary vs Blue Green: come eliminare il downtime

Guida sulle strategie di rilascio software: scopri come Blue Green e Canary deployment possono proteggere il tuo business e migliorare l'esperienza utente.

Architetture Esagonali: una nuova prospettiva con ports and adapters

Architettura

Ottobre 2025

Architetture Esagonali: una nuova prospettiva con ports and adapters

Scopri l'architettura esagonale (ports and adapters): principi, vantaggi, esempi pratici e come migliorare testabilità, manutenibilità e flessibilità nei progetti software moderni.

Agent as a Service (AaaS): il futuro oltre il SaaS

Architettura

Agosto 2025

Agent as a Service (AaaS): il futuro oltre il SaaS

Scopri il modello Agent as a Service (AaaS): come gli agenti AI autonomi stanno rivoluzionando il software, superando il SaaS e trasformando processi e business.

SST: il futuro del serverless su AWS

Architettura

Luglio 2025

SST: il futuro del serverless su AWS

Scopri SST (Serverless Stack): il framework che rivoluziona lo sviluppo serverless su AWS. Vantaggi, esperienza d'uso, scalabilità e best practice per progetti cloud-native.

Firebase real-time database: la scelta giusta per applicazioni in tempo reale?

Architettura

Giugno 2025

Firebase real-time database: la scelta giusta per applicazioni in tempo reale?

Scopri i vantaggi, i limiti e le alternative di Firebase real-time database: guida completa per scegliere la soluzione ideale per app e piattaforme in tempo reale.

Software architecture: quale usare?

Architettura

Maggio 2025

Software architecture: quale usare?

Guida alle principali architetture software: vantaggi, svantaggi e casi d'uso di client-server, layered, microservizi, event-driven, serverless e altri modelli per progetti moderni.

Microservizi o monolite: dibattito ancora attuale?

Architettura

Marzo 2025

Microservizi o monolite: dibattito ancora attuale?

Microservizi vs monolite: vantaggi, svantaggi e scenari d'uso per scegliere l'architettura software più adatta al tuo progetto nel 2025.

AWS, Cloudflare, Supabase e gli altri: quale scegliere?

Architettura

Febbraio 2025

AWS, Cloudflare, Supabase e gli altri: quale scegliere?

Guida alla scelta del provider cloud ideale: confronto tra AWS, Cloudflare, Supabase, Google Cloud, Azure, DigitalOcean, Vercel, Netlify e Heroku per ogni esigenza di progetto.

Le fallacie dei sistemi distribuiti

Architettura

Gennaio 2025

Le fallacie dei sistemi distribuiti

Scopri le principali fallacie dei sistemi distribuiti e come evitarle: resilienza, sicurezza, scalabilità e best practice per progettare architetture moderne e affidabili.