1) O documento discute o uso do Kafka no LinkedIn para suportar o processamento de 1,4 trilhões de mensagens por dia e 175 terabytes de dados. 2) O Kafka foi projetado para mover dados de alta performance de forma distribuída e escalável, servindo como uma única fonte de verdade para o LinkedIn. 3) O documento explica os principais conceitos do Kafka como tópicos, partições, produção e consumo de dados.

2. @waldyrfelix
@waldyrfelix
@waldyrfelix
dev.to/wfelix
Head de Arquitetura de Software no
LinkApi, mais de 13 anos
desenvolvendo produtos escaláveis,
eterno estudante, professor e
palestrante.

3. Volume
● 1.4 trilhões de mensagens por dia
● 175 terabytes trafegados por dia
● picos de 13 milhões de msg/s
● aproximadamente 2,75 GB/s

4. Sem o Kafka o LinkedIn não seria capaz de
suportar o próprio crescimento

6. 1. Kafka foi desenhado para mover
dados em alta performance
2. Distribuído nativamente e por padrão,
garantindo recuperação de falhas
3. Tem sido utilizado como
“single source of truth”

7. 1. Flexível para publish/subscribe
2. Baixo acoplamento
3. Escalável horizontalmente
4. Alta vazão de dados (throughput)
5. Reliable & Durable
6. Usa tópicos ao invés de filas

8. Aplicações mais comuns:
● Message broker
● Storage system
● Streams processor

10. API Producer permite que aplicações
possam enviar streams para os tópicos
do Kafka.
Já as aplicações que lêem dados do
Kafka usam a API Consumer.

11. Para realizar operações com input e output
de dados sem tirar as mensagens do Kafka
usa-se a API de Streams.
A extração de dados de sistemas ou banco
de dados existentes pode ser feita usando
API Connectors.

13. Um topic é um stream que atua como
um banco de dados;
Possui armazenamento persistente;
Um tópico tem diversas partições, cada
uma definida por um número;
A quantidade de partições é definida na
criação do tópico.

14. As partições são independentes;
Ordenadas e a sequência dos registros
são imutáveis;
O offset é posição de um registro na
partição, ID sequencial e único do dado.

16. Os producers adicionam registros ao
stream sempre na cauda da partição;
Os consumers controlam o offset que
desejam ler;
Os consumers podem ler e reler as
mensagens sem “perdê-las”;
É possível criar consumer groups.

17. Se todos os consumers estiverem dentro
do mesmo consumer group, as mensagens
são entregues separadamente como um
load balancer.

18. Mas se os consumers estiverem em
consumer groups diferentes, as mensagens
são entregues para todos como um
broadcast.

20. Cada partição é replicada em diversos
brokers, de acordo o replication-factor;
Isto garante que um dado nunca seja
perdido;
Cluster possui a estratégia de
controllers, leaders e followers.

21. Implementando
um Pub/Sub
com Kafka

22. Criar conta no
https://confluent.cloud

23. npm install node-rdkafka --save

24. github.com/waldyrfelix/rocketseat-kafka

25. file: .env
KAFKA_URI = <host>
KAFKA_KEY = <key>
KAFKA_SECRET = <secret>
KAFKA_TOPIC = <topic>
KAFKA_CONSUMER_GROUP = <consumer-group>

26. Obrigado :)
dev.to/wfelix
insta / twitter / linkedin
@waldyrfelix