Arquitetura de

Microsserviços: Padrão
Saga Orquestrado
Conceitos de transações distribuídas e sagas
na arquitetura de microsserviços.

Victor Hugo Negrisoli

Desenvolvedor Back-End
 Quem sou eu?
• Prazer, meu nome é Victor Hugo Negrisoli!

• Formado em Ciência da Computação pelo Centro Universitário Filadélfia (UniFil –

Londrina, PR) e Pós-Gaduado em Ciência de Dados & Big Data na PUC-MG.

• Aprox. 7 anos de atuação no mercado de tecnologia.

• Instrutor aqui na Udemy, com 3 cursos publicados, e dono do canal Comics & Code,
que tem conteúdos sobre programação e quadrinhos.

• Atualmente sou Desenvolvedor Back-End Especialista e trabalho com tecnologias

Java | Spring e com tecnologias Node.js.

• Atuo principalmente com desenvolvimento de APIs e arquitetura de

microsserviços.

• Redes sociais: LinkedIn, GitHub, Gmail.

 O que irei aprender e desenvolver
neste curso?
• Iremos estudar os conceitos práticos e teóricos acerca de padrões para
implementação de arquitetura de microsserviços.

• Iremos entender o conceito de uma Transação Distribuída, e o que ela

representa no mundo de microsserviços.

• Iremos estudar o padrão Saga e suas duas implementações: Orquestrado

e Coreografado.

• Neste curso, implementaremos o padrão Saga Orquestrado.

• Nós utilizaremos Java 17 com Spring Boot 3 como framework web de

desenvolvimento.
 O que irei aprender e desenvolver
neste curso?

• Utilizaremos PostgreSQL para armazenar os dados das transações e

MongoDB para armazenar os dados do pedido.

• Utilizaremos também o Docker e o docker-compose para executar os

nossos containers durante o desenvolvimento.

• Utilizaremos o Apache Kafka como nosso Message Broker, responsável

por gerenciar os eventos na nossa arquitetura.

• Todo o material do curso, links, PPTs, códigos e repositórios estarão

disponibilizados com os alunos.
Iremos construir a seguinte arquitetura
 Microsserviços
Soluções e desafios que acompanham.

Victor Hugo Negrisoli

Desenvolvedor Back-End
 Microsserviços - Soluções que acompanham

• Microsserviços são uma

abordagem arquitetônica e
organizacional do desenvolvimento
de software na qual o software
consiste em pequenos serviços
independentes que se comunicam
usando APIs bem definidas.

• Esses serviços pertencem a

pequenas equipes
autossuficientes.
 Microsserviços - Soluções que acompanham

E solucionam problemas relacionados a:

• Delimitação por domínio

• Escalabilidade e alta disponibilidade

• Entrega contínua

• Resiliência e tolerância a falhas

 Microsserviços - Soluções que acompanham

• Inovação e a possibilidade de atuar com diversas tecnologias distintas.

• São altamente sustentáveis e testáveis.

• Diminui o acoplamento entre os domínios de negócio.

• Implantável de forma independente.

• São geralmente construídos com base em especificações de domínio do

negócio e são propriedade de uma pequena equipe responsável.
 Microsserviços - Desafios que acompanham

Ao mesmo tempo que trazem ganhos e soluções, também são

acompanhados de em alguns desafios, tais quais:

• Forte necessidade de governança.

• Aumento da complexidade do sistema.

• Maiores pontos de falha.

• Grande necessidade de métricas, observabilidade e rastreamento.

 Microsserviços - Desafios que acompanham

• Cada microsserviço possui seu próprio banco de dados (não é

obrigatório, porém é uma questão de boa prática), e é excelente para o
isolamento do serviço, porém, traz o problema para gerenciar as
transações distribuídas.

• Caso a arquitetura não seja devidamente planejada, ou uma transação

distribuída não seja devidamente tratada, podem ocorrer problemas
relacionados à inconsistência de dados, ou seja, um dado em um
microsserviço X é um, e o mesmo dado em um microsserviço Y é outro, e
isso pode trazer muito problema.

• Inconsistência de dados geralmente leva à ocorrência de diversos

chamados de incidentes em produção.
 Transações Distribuídas
Conceito, o problema que trazem, e diferentes formas de tratar.

Victor Hugo Negrisoli

Desenvolvedor Back-End
 Transações Distribuídas - Conceito
• Transações distribuídas são aquelas que iniciam em um microsserviço,
mas ela só é finalizada em outro de maneira conceitual.

• A palavra conceitual aparece aqui pois a transação distribuída é apenas

interpretada, ou seja, é apenas simbólica no fluxo de execução entre os
microsserviços, e não algo 100% concreto como uma transação em um
banco de dados.

• Uma transação em um banco de dados é o processo de execução de

várias operações de leitura e escrita em um banco de dados que, ao seu
fim, é concretizada de maneira atômica, ou seja, ou tudo é aplicado no
banco de dados, ou todas as alterações são desfeitas a fim de realizar a
consistência de dados, seguindo os conceitos do A.C.I.D.
 Transações Distribuídas - Conceito
• Mas, em uma arquitetura de microsserviços, cada serviço participante
possui seu próprio banco de dados, ou seja, cada chamada a um
microsserviço gera uma própria transação interna em suas bases.

• O conceito de uma transação distribuída então é aplicada a um contexto,

ou seja, um fluxo que é iniciado e que altera o estado dos microsserviços
e que, embora não estejam na mesma transação atômica, pertencem ao
mesmo contexto.

• Caso um serviço esteja com uma informação e outro não, e pertençam

ao mesmo contexto aplicado, então, temos uma inconsistência de dados.
 Transações Distribuídas – Problemas que
acompanham
Imagine o seguinte cenário:
1. Um serviço de vendas (Order Service) recebe uma requisição de um novo pedido e persiste em seu banco de dados.
2. O serviço Order Service envia uma requisição ou evento para o serviço de pagamento (Payment Service).
3. O serviço de pagamento tenta realizar o pagamento e persiste em sua base.
4. O serviço de pagamento envia uma requisição ou evento ao serviço de produtos (Product Service) para atualizar o
estoque.
5. O serviço de produtos atualiza corretamente o estoque e o fluxo de venda é finalizado.
 Transações Distribuídas – Problemas que
acompanham
Tudo que vimos ali foi o cenário positivo, num mundo de sonhos em que tudo dá certo! Agora, pense o seguinte:
1. Vamos supor que ocorra um erro na tentativa de atualização de estoque, seja por um bug no código, seja por uma falha
na requisição HTTP, message broker indisponível, entre outros.
2. Nosso fluxo não foi concluído, temos um pedido aberto, temos uma tentativa de pagamento realizada, mas o estoque
está incorreto, ou seja, temos dados inconsistentes.
3. É possível criar fluxos para realizar o cancelamento do pagamento, mas e se tivermos várias transações anteriores?
 Transações Distribuídas – Problemas que
acompanham
1. Qual seria a estratégia necessária para desfazer todo o fluxo e evitar dados inconsistentes?
2. Como garantir que uma transação será sempre atômica?
3. Além de garantir atomicidade, como manter escalável em uma arquitetura composta por vários serviços, sem utilização de
2PC (Two-Phase Commit Protocol) em seu fluxo?
4. Para quê ter todo esse trabalho? O que dados inconsistentes podem influenciar ou impactar no dia-a-dia de gestores e
desenvolvedores?
 Transações Distribuídas – Diferentes
formas de tratar

Existem padrões de arquitetura de microsserviços que podem ser implementados para evitar
problemas de dados inconsistentes em transações distribuídas, iremos falar sobre 3 deles:

Padrão Saga Orquestrado Padrão Saga Coreografado Padrão Outbox

 Transações Distribuídas – O problema do 2PC
• O 2PC, ou Two-Phase Commit Protocol, como o próprio nome diz, é um protocolo atômico, ou seja, elabora uma
estratégia para realizar um commit em duas etapas em uma transação distribuída.

• Geralmente funciona de maneira síncrona, com requisições HTTP, a estratégia consiste em iniciar um fluxo, realizar
requisições HTTP para os serviços envolvidos para validar se o serviço tem o necessário para persistir uma informação
(fase 1), e em seguida, realizar outra requisição para cada serviço, persistindo a informação desejada (fase 2).

• O problema dessa estratégia é que, em qualquer cenário de falha, os dados ficam inconsistentes.
Saga Orquestrado e Coreografado
Conceitos, vantagens e desvantagens
 Padrão Saga - Conceitos
• É um padrão que tem como objetivo garantir a execução de sucesso de um fluxo de transações,
e também garantir que em caso de falha, todas as alterações sejam desfeitas na sequência que
foram realizadas.

• Existem dois tipos de implementação do padrão saga, Orquestrado e Coreografado.

 Padrão Saga - Conceitos

• Demanda complexidade de implementação, porém, resolve

problemas de inconsistência de dados entre serviços.

• Não utiliza estratégia de 2PC (Two-Phase Commit Protocol)

e funciona de maneira assíncrona.
 Padrão Saga Orquestrado

• Consiste na ideia de um orquestrador, ou

seja, um agente externo aos microsserviços
envolvidos, que fica responsável por
orquestrar, isto é, determinar qual será a
ordem de envio dos eventos baseados em
casos de sucesso e falha.

• Nesta estratégia, apenas o orquestrador

deve conhecer os serviços que serão
executados na ordem conforme a resposta,
os microsserviços envolvidos devem ser
totalmente independentes e não ter
conhecimento de qual será o próximo ou
anterior.
 Padrão Saga Orquestrado

• Estratégia bastante recomendada para uma

arquitetura já existente de microsserviços
que ainda não utilize saga e que possua
vários serviços implementados, pois acopla
toda a lógica de orquestração em apenas
um local.

• O orquestrador deve garantir o rollback de

todos os serviços em caso de uma falha.
 Padrão Saga Orquestrado - Vantagens
• Toda a lógica da saga fica em apenas um local centralizado, diminuindo a
possibilidade de falhas em relação à orquestração dos eventos.

• Maior testabilidade dos fluxos.

• Os microsserviços envolvidos são totalmente independentes, não possuem o

mínimo de conhecimento sobre a orquestração, facilitando na implementação e
compreensão dos fluxos unitariamente.

• É preferencial para implementar em uma arquitetura já existente e com grandes

fluxos de transações distribuídas.
 Padrão Saga Orquestrado - Desvantagens

• Apesar de toda a lógica ficar centralizada, há a necessidade de incluir e manter

mais um microsserviço na arquitetura, necessitando acompanhamento, logs,
manutenção.

• Se o microsserviço de orquestração ficar fora, todo o fluxo é encerrado.

 Padrão Saga Coreografado

• Consiste na ideia de uma coreografia existente entre os microsserviços, ou seja, o próprio serviço possui a
lógica para saber qual será o próximo passo a ser decidido no fluxo com base no resultado da iteração
atual, seja sucesso ou falha.
• Nesta estratégia, o próprio serviço tem conhecimento dos próximos serviços que serão executados na
ordem conforme a resposta.
 Padrão Saga Coreografado

• Estratégia bastante recomendada para uma

arquitetura que está ainda em estágio inicial de
desenvolvimento, evita a necessidade de
manter mais um serviço de orquestração, e não
tem retrabalho de implementação devido ao
novo surgimento da arquitetura.

• O próprio serviço deve garantir o próprio

rollback e deve garantir que será feito o rollback
do serviço anterior no fluxo de execução.
 Padrão Saga Coreografado - Vantagens

• Não há a necessidade de manter mais um microsserviço.

• Excelente para arquiteturas ou fluxos de transações pequenas, que não envolvam

muitos serviços.

• É preferencial que seja implementado caso a arquitetura esteja nascendo, onde os

fluxos ainda não estão definidos e envolvendo vários serviços.
 Padrão Saga Coreografado -
Desvantagens

• Maior complexidade para entender e manter a lógica conforme ocorra um grande

crescimento do fluxo das transações.

• Os microsserviços não são independentes, eles precisam conhecer quem vem

antes ou depois no fluxo de execução.

• Pode ser mais complexo de ser testado devido o conhecimento geral dos
microsserviços envolvidos.
 Padrão Saga – Saga Execution
Controller

• Tanto a estratégia de saga orquestrado ou coreografado vão utilizar um

conceito que chamamos de Saga Execution Controller ou SEC, que nada
mais é, como o próprio nome especifica, o objeto ou entidade
controladora de execução do saga.

• Caso esteja implementando um saga orquestrado, o SEC será o próprio

orquestrador, ou seja, o serviço como um todo, responsável por receber
e enviar eventos com base em seu estado atual.
 Padrão Saga – Saga Execution
Controller

• Caso esteja implementando um saga

coreografado, o SEC será implementado
em cada serviço participante da saga,
sendo este um objeto, uma classe
contendo a lógica da saga, ou até um
objeto externo, contanto que ele apenas
redirecione os eventos, mantendo a
lógica de conhecimento da ordem de
execução para o próprio serviço, caso
contrário torna-se uma orquestração e
não coreografia.
 Padrão Outbox
Conceitos, vantagens e desvantagens
 Padrão Outbox - Conceitos

• A ideia do Outbox é, sempre que houver a

necessidade de enviar um evento a um Message
Broker, ao invés de realizar o envio direto no fluxo de
processamento, salvar o conteúdo do evento em uma
tabela que represente o Outbox, e enquanto isso,
algum processo separado irá ler a tabela Outbox e
tentar realizar a produção dos eventos encontrados.
• Assim que uma mensagem for enviada com sucesso,
o registro deverá ser removido da tabela de Outbox,
garantindo o seu envio.
• A estratégia de leitura das mensagens pode ser algum
agendador ou até mesmo leitura diretamente dos
logs da alteração da tabela utilizando ferramentas
como Debezium.
 Padrão Outbox - Vantagens

• A motivação para a utilização desta estratégia é

para que possa garantir que caso ocorra uma
falha de processamento em um fluxo, ou até
mesmo uma falha do Message Broker, o
conteúdo do evento não será perdido,
garantindo seu envio em algum momento.

• No padrão saga, embora o problema de

rollback da transação seja resolvido, ainda
assim, caso o Message Broker falhe em algum
ponto, poderá ocasionar em perda da
informação.
 Padrão Outbox - Vantagens

• Com o Outbox, a informação ficará persistida em uma estrutura criada na aplicação,

e, neste caso, haverão várias tentativas de envio até que o evento seja removido da
tabela.

• Com essa aboragem, é estritamente importante a implementação de estratégias de

idempotência.

• Essa padrão pode ser implementado junto do padrão Saga, independente da

abordagem orquestrada ou coreografada.
 Padrão Outbox - Desvantagens

• Aumenta muito mais a complexidade de implementação e entendimento dos fluxos.

• Necessidade de ter uma tabela de Outbox em todos os serviços que utilizarem esta
abordagem.

• Necessidade de ter algum recurso extra de processamento, Debezium, schedulers

separados, entre outros.

• Possibilidade de duplicidade de eventos, necessitando da implementação de

idempotência nos fluxos.
Event-Driven Architecture (EDA)
Conceitos e aplicações
 Event-Driven Architecture -
Conceitos
• Também chamada de EDA (Event-Drive Architecture) ou Arquitetura Orientada a Eventos.
• Uma arquitetura orientada a eventos usa eventos para acionamento e comunicação entre
serviços desacoplados e é comum em aplicações modernas criadas com microsserviços.
 Event-Driven Architecture -
Conceitos
• É um estilo de arquitetura de software em que a troca de informações e a
coordenação de componentes são baseadas em eventos.

• Nesse estilo arquitetural, os componentes do sistema são projetados para

reagir e responder a eventos, que são notificações assíncronas de
ocorrências relevantes no sistema, como a criação de um objeto, uma
atualização de estado, ou um evento de negócio específico.

• Os principais tópicos sobre a EDA é reatividade, assincronicidade,

desacoplamento e escalabilidade.
 Event-Driven Architecture - Aplicações
• Diferente do que vimos sobre padrão Saga Orquestrado, Coreografado e
padrão Outbox, a EDA não possui uma implementação física, e sim é um
desenho arquitetural, ou seja, você implementa sua arquitetura seguindo o
modelo da EDA.
• O padrão Saga e o Padrão Outbox não são conceitos da EDA, e sim padrões
existentes para tratar problemas envolvendo transações distribuídas, porém,
o fato de você trabalhar com transações distribuídas, processamento
assíncrono via eventos, se devidamente implementados, estão dentro dos
conceitos desta arquitetura.
• Message Brokers como Apache Kafka e RabbitMQ são duas ferramentas que
contribuem para a implementação desta arquitetura.
Apache Kafka
Conceitos e aplicações
 Apache Kafka – Conceitos e
aplicações
• O Apache Kafka é uma plataforma de streaming de eventos distribuída de código
aberto usada por milhares de empresas para pipelines de dados de alto desempenho,
análise de streaming, integração de dados e aplicativos de missão crítica.
• É considerado um Message Broker, mas não apenas isso, ele é todo um ecossistema
de streaming de eventos de maneira distribuída.
• Trabalha em cima dos conceitos de tópicos, pub/sub (publisher e subscriber),
particionamento, grupos de consumo, entre outras características.
• Pode ser implementado por várias linguagens e frameworks.
• É bastante robusto, resiliente e escalável.
 Apache Kafka – Conceitos e
aplicações
No Apache Kafka, trabalharemos com alguns conceitos, tais como:
• Tópico: é um canal de comunicação de eventos, definidos por um nome, onde
produtores publicam eventos e consumidores as consomem.
• Producer: é o componente responsável por publicar (produzir) eventos em um
ou mais tópicos.
• Consumer: componente responsável por consumir eventos de um ou mais
tópicos, e processá-los de acordo com a lógica de negócio do sistema.
• Consumer group: é o conjunto de consumidores que trabalham juntos para
consumir eventos de um ou mais tópicos de forma coordenada, permitindo
uma maior escalabilidade e tolerância a falhas na leitura de eventos do Kafka.
 Apache Kafka – Conceitos e
aplicações
• Offset: identificador único associado a cada evento em
um tópico, indicando a posição relativa do evento
dentro do tópico. Os offsets são usados pelos
consumidores para rastrear o progresso da leitura de
eventos e retomar a partir de uma posição específica
em caso de falhas ou reinicializações. Os offsets podem
ter um reset do tipo earliest ou latest.
• Earliest: caso um novo consumidor seja criado ou seja
feito um reset, ele reprocessará todos os eventos do
tópico desde o início do offset.
• Latest: caso um novo consumidor seja criado ou seja
feito um reset, ele reprocessará apenas o último evento
no offset do tópico.
 Apache Kafka – Conceitos e
aplicações
• Partitions: divisões lógicas de um tópico que permitem
a distribuição e paralelização do processamento de
eventos em diferentes nós de um cluster do Kafka. Cada
partição é ordenada e tem um conjunto exclusivo de
offsets, e várias partições podem ser usadas para
aumentar a capacidade de leitura/gravação em um
tópico, permitindo um alto nível de escalabilidade e
desempenho no Kafka.
• Réplicas: são cópias de uma partição de um tópico que
são armazenadas em diferentes nós (brokers) dentro de
um cluster Kafka. As réplicas são usadas para garantir a
redundância e a alta disponibilidade dos dados.
• Ou seja, réplicas são a nível de cluster, e partições são a
nível de tópicos.
 Apache Kafka – Conceitos e
aplicações
• Quando trabalhamos com particionamento,
estamos falando a nível de tópicos. Os
particionamentos dividem os envios dos eventos
aos grupos de consumo (consumer groups).

• Caso você tenha um tópico com 4 partições e 2

consumers, então 2 consumers receberão os
eventos paralelamente de 2 das 4 partições, e o
outro consumer receberá das demais.

• Cada partição é consumida por apenas um

consumidor em um grupo de consumo em um
determinado momento.
 Apache Kafka – Conceitos e
aplicações
• Outro conceito bastante importante para sabermos é relacionado à Idempotência.

• A idempotência é um conceito que se aplica a operações ou ações que podem ser repetidas
várias vezes sem causar efeitos colaterais adicionais ou alterar o resultado final além da
primeira execução.

• A idempotência no Kafka refere-se à capacidade de produzir eventos de forma segura e

garantir que o mesmo evento seja processado apenas uma vez, mesmo que seja produzido
várias vezes pelo produtor.

• Como o Kafka é uma ferramenta distribuída, é possível que um tópico consiga consumir um
mesmo evento mais de uma vez, pense o seguinte cenário:
 Apache Kafka – Conceitos e
aplicações
1. Temos um tópico com 4 partições, e 2 consumers, que irão consumir os eventos de cada uma
das 2 partições.

2. Neste caso, o nosso produtor quer garantir a entrega do evento, e ele sempre publicará no
tópico o mesmo evento 4 vezes, para garantir que as 4 partições recebam o evento.

3. Se o mesmo evento for publicado nas 4 partições e cada um dos 2 consumers consumirem de 2
partições, então, nós iremos consumir o mesmo evento mais de uma vez.

4. Neste caso, mesmo criando uma chave única de publicação utilizando key value, o problema
será que a key será sempre distinta e o value será sempre igual, neste caso, é interessante que a
gente implemente uma estratégia para identificação de um evento idêntico, no caso, algum ID
que represente aquele contexto.
 Apache Kafka – Conceitos e
aplicações
• Para isto, podemos usar um ID que iremos persistir nos serviços para identificar que todos os
eventos daquele payload sejam relacionados a este contexto específico.

• Um exemplo do nosso projeto, sempre que gerarmos um pedido, antes dele ser comunicado aos
tópicos do Kafka, nós geraremos um UUID e um OrderID (ID do MongoDB), e estes 2
identificadores sempre estarão no payload dos eventos.

• Com isso, em cada microsserviço, nós iremos persistir nossas ações vinculadas a esses 2 ids, e
sempre iremos validar se já não existe uma interação para esses 2 ids, garantindo que nunca
repita uma ação que não pode ser repetida, por exemplo, atualização de estoque dos produtos ou
tentativa de realização de pagamento.
 Apache Kafka – Tópicos ou Filas?
• É muito comum a confusão entre tópicos e filas, principalmente quando falamos
sobre o Kafka, porém, são conceitos diferentes, o Kafka trabalha com tópicos e não
filas. Inclusive é muito comum a confusão de pessoas que não conhecem o Kafka e
pensam que é uma alternativa ao RabbitMQ e que faz a mesma coisa, mas não!

• Tópicos são canais de comunicação que permitem a publicação e subscrição de

eventos, enquanto filas em sistemas de mensagens tradicionais são estruturas de
armazenamento temporário de mensagens.

• Diferenças básicas dos tópicos em relação às filas são retenção de eventos,

persistência, particionamento, escalabilidade e modelos diferentes de publicação e
subscrição.
 Apache Kafka ou RabbitMQ?
• Como dito, muitos acham que são apenas alternativas que fazem a mesma coisa.

• Porém, o Kafka e o Rabbit se diferenciam em várias coisas, como no modelo de mensageria,

enquanto o Kafka trabalha com streaming de eventos distribuídos, o RabbitMQ é baseado em
filas, em que são armazenadas até seu consumo. O Kafka é desenhado para entregar de maneira
distribuída, particionada e altamente escalável, e mesmo que o RabbitMQ também possa ser
escalado verticalmente, ele é mais recomendado para cargas de trabalho com menor volume.

• O Kafka possui persistência de eventos de maneira nativa e padrão, enquanto o Rabbit não,
mesmo podendo ser configurável através de plugins.

• O Kafka possui garantia de entrega do evento por padrão, enquanto o RabbitMQ mesmo tendo a
possibilidade, não trabalha com esta abordagem por padrão.
 Referências
• O que são microsserviços? https://aws.amazon.com/pt/microservices/
• What are microservices? https://microservices.io/
• Usando Saga para garantir consistência de dados em ambientes distribuídos
https://sidhartarezende.medium.com/usando-saga-para-garantir-consist%C3%AAncia-de-dados-em-ambientes-distribu%C3%A
Ddos-2edad93798c7
• Padrão SAGA para arquitetura de Microsserviços:
https://www.zup.com.br/blog/padrao-saga-para-arquitetura-de-microsservicos
• Pattern: Saga https://microservices.io/patterns/data/saga.html
• Saga Pattern in Microservices https://www.baeldung.com/cs/saga-pattern-microservices
• SAGA Pattern Briefly https://medium.com/trendyol-tech/saga-pattern-briefly-5b6cf22dfabc
• Saga Orchestration for Microservices Using the Outbox Pattern https://www.infoq.com/articles/saga-orchestration-outbox/
• [MICROSERVICES] Outbox Pattern https://medium.com/@victorhsr/microservices-outbox-pattern-a4344d8ed0b
• Pattern: Transactional Outbox https://microservices.io/patterns/data/transactional-outbox.html
• Patterns for distributed transactions within a microservices architecture
https://developers.redhat.com/blog/2018/10/01/patterns-for-distributed-transactions-within-a-microservices-architecture
 Referências
• Apache Kafka: https://kafka.apache.org/intro
• Entendendo como o Consumidor Kafka funciona:
https://medium.com/@alvarobacelar/entendendo-como-um-consumidor-kafka-funciona-ee72237904c8
• Entendendo o Apache Kafka I: https://medium.com/luizalabs/entendendo-o-apache-kafka-i-27342ec9e29
• How to Develop a Winning Kafka Partition Strategy: https://www.openlogic.com/blog/kafka-partitions
• Apache Kafka: Introduction: https://kafka.apache.org/intro
• Event-driven Architecture (EDA) em uma Arquitetura de Microsserviços:
https://medium.com/@marcelomg21/event-driven-architecture-eda-em-uma-arquitetura-de-micro-servi%C3%A7os-1981614c
dd45
• O que é uma arquitetura orientada por eventos?: https://aws.amazon.com/pt/event-driven-architecture/
• Event-driven architecture style: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
• Pattern: Event-driven architecture: https://microservices.io/patterns/data/event-driven-architecture.html
 Muito obrigado!

Victor Hugo Negrisoli

Desenvolvedor Back-End