API vs Event Streaming: O Que Muda Para Quem Testa?

API vs Event Streaming: O Que Muda Para Quem Testa?

# testing# braziliandevs# beginners# eventdriven
API vs Event Streaming: O Que Muda Para Quem Testa?Alicia Marianne 🇧🇷

✨ Oi, gente! Recentemente, tenho pensado bastante em como contribuir para a comunidade de QA e...

Oi, gente!

Recentemente, tenho pensado bastante em como contribuir para a comunidade de QA e ajudar aqueles que estão começando ou que já estão há algum tempo na área. Também quero relatar mais sobre os desafios de ser uma brasileira morando em terras lusitanas 🇵🇹.

O que me levou a querer voltar — na verdade, começar — a escrever na minha língua materna?

Bom, se eu fosse dizer de bate-pronto: saudade. 💛

Sim, aqui em Portugal fala-se português também, porém, como boa mineira que sou, sinto falta do nosso jeitinho de falar e escrever as coisas. Acredito que falar sobre o que sei na minha língua materna me deixa mais próxima de casa.

Outra razão que me fez querer começar a escrever em português foi voltar a ser mais ativa em comunidades de desenvolvimento (He4rt 💜). Tenho visto muitas mulheres entrando para a área, e algumas não são fluentes em inglês ou não confiam no que sabem para se arriscar em conteúdos em outros idiomas.

Com isso, eu pensei: por que não focar por um tempo em escrever em português? E cá estamos! ✍️

E, para que isso não seja apenas um comunicado, mas algo útil, já vou começar falando sobre serviços de mensageria (Event Streaming) e por que é importante que um QA (ou aspirante a QA) entenda pelo menos o básico sobre isso.


📡 Em termos técnicos

Event Streaming (Transmissão de Eventos) é a prática de capturar dados em tempo real a partir de fontes como bancos de dados, sensores, dispositivos móveis, serviços na nuvem e aplicações de software, na forma de fluxos de eventos; armazenar esses fluxos de forma duradoura para recuperação posterior; manipular, processar e reagir a esses eventos tanto em tempo real quanto retrospectivamente; e encaminhá-los para diferentes destinos, conforme necessário.

Lindo, né? 😅

Mas como podemos entender isso na prática?


🧠 Vamos imaginar o seu corpo

Sim, ele mesmo!

Você sente aquela dor no estômago 🍽️, que é um sinal de que está com fome. Esse sinal “fala” para o seu cérebro:

— Querido, estou precisando de nutrientes. Quando eles chegam?

Normalmente, você para o que está fazendo e vai comer algo. Mas perceba: seu estômago precisa esperar até o momento certo. Ainda assim, seu corpo continua funcionando normalmente. Ele não para.

No mundo do software, isso significa que, sempre que existir um sinal ou uma modificação, essa informação será interpretada sem que outras funcionalidades do sistema sejam interrompidas.


🛒 Exemplo prático: compras online

  • Você faz o seu pedido
  • Realiza o pagamento
  • O sistema de pagamento processa esse pagamento
  • Ele publica um evento informando que o pagamento foi aprovado
  • O sistema de notificação consome esse evento
  • E o cliente recebe a confirmação de que a compra será entregue 📦

Tudo isso pode acontecer sem que um sistema precise “esperar parado” pelo outro.


🔧 Algumas ferramentas de Event Streaming

Hoje, existem várias ferramentas no mercado que trabalham com esse modelo de comunicação baseada em eventos. Algumas das mais conhecidas são:

  • Apache Kafka 🐘 (uma das mais populares no mercado)
  • RabbitMQ 🐰
  • AWS Kinesis

Cada uma tem suas particularidades, mas todas trabalham com o conceito de produtores, consumidores e eventos trafegando por tópicos ou filas.

E aqui começa a parte interessante para nós, QAs. 👀


🔄 Event Streaming vs API

Você pode se perguntar:

“Alicia, mas qual a diferença disso para uma API? Eu consigo fazer o mesmo apenas chamando uma API.”

Conseguir, você consegue. Mas será que é a melhor opção? 🤔

Depende.

Normalmente, sistemas que utilizam apenas APIs (geralmente síncronas) funcionam assim: fazem uma requisição, esperam a resposta, e só depois continuam o processamento. Isso pode deixar o sistema mais acoplado e dependente.

Já em um sistema de Event Streaming (assíncrono), não é necessário esperar uma resposta para continuar o fluxo. O sistema segue funcionando enquanto os eventos são processados em paralelo.

E, principalmente, não queremos que o usuário fique esperando uma resposta para continuar usando o software ⏳.


🧪 E onde o QA e automação entram nisso?

Quando falamos de sistemas orientados a eventos, surgem novas perguntas de teste:

  • O evento foi realmente publicado?
  • O formato (schema) está correto?
  • O consumidor está processando corretamente?
  • O que acontece se o consumidor falhar?
  • Existe retry?

Percebe como o nível de complexidade aumenta?

Testar Event Streaming não é só validar payload. Envolve entender fluxo, consistência eventual, ordenação de mensagens, tolerância a falhas e comportamento assíncrono e partir dessa compreensão, é possível pensar em automações, do tipo:

  • Produzir eventos automatizados para testes
  • Validar consumo de mensagens
  • Testes de contrato (como com Schema Registry no Kafka)
  • Testes de integração ponta a ponta
  • Validação de mensagens em filas durante pipelines de CI/CD

✅ Conclusão

Entender mensageria e Event Streaming não é apenas “coisa de backend” — é conhecimento essencial para qualquer QA que queira testar sistemas modernos com mais profundidade. 💡

Quando compreendemos como os eventos trafegam, como os sistemas se comunicam de forma assíncrona e onde podem ocorrer falhas, ampliamos nossa capacidade de análise, criamos melhores cenários de teste e nos tornamos profissionais mais estratégicos.

Escrever sobre isso em português é, para mim, uma forma de compartilhar conhecimento, fortalecer a comunidade e também me sentir mais próxima de casa. 💛

E esse é só o começo. 🚀