Microsserviços, REST e eventos: como diferenciar os modelos na prova

Olá, querido(a) aluno(a)!

Um portal recebe uma solicitação, consulta um cadastro e envia uma notificação. Essa descrição parece simples, mas pode envolver decisões muito diferentes: quantas aplicações serão implantadas, quem é responsável por cada dado, quando o usuário recebe resposta e o que acontece se uma mensagem chegar duas vezes. É nesse ponto que a comparação entre microsserviços, REST e eventos se torna importante.

Esses conceitos não são três opções mutuamente excludentes. Eles respondem a perguntas distintas e podem coexistir. Neste artigo, você aprenderá a identificar essas perguntas, analisar vantagens e limitações e resolver situações de prova sem depender da aparência de um diagrama. Os exemplos e exercícios são autorais; não representam estatísticas de cobrança nem questões atribuídas a bancas.

1. O que são microsserviços, REST e eventos?

Microsserviços são um estilo arquitetural baseado em serviços pequenos e autônomos, organizados em torno de capacidades de negócio. A implantação independente é uma característica importante, assim como a delimitação de responsabilidades. O tamanho não deve ser interpretado como um número obrigatório de linhas de código. Uma divisão em serviços pode aumentar a capacidade de evolução, mas também introduz custos operacionais e de comunicação. Documentação de arquitetura de microsserviços da Microsoft.

REST significa Representational State Transfer, ou transferência de estado representacional. O estilo foi descrito por Roy Fielding em sua tese de 2000. Entre suas restrições estão cliente-servidor, ausência de estado de sessão no servidor, cache, interface uniforme, sistema em camadas e código sob demanda, sendo a última opcional. REST não é um protocolo, um formato de arquivo ou um sinônimo de microsserviço. Definição original de REST.

Uma arquitetura orientada a eventos organiza interações a partir de fatos produzidos e consumidos por componentes. Um evento como “Solicitação recebida” informa algo que aconteceu. Produtores, consumidores e canais de eventos compõem esse arranjo. O desacoplamento entre participantes pode facilitar novas integrações, mas exige cuidado com entrega, ordem e consistência. Referência de arquitetura orientada a eventos.

Não existe uma “versão atual dos microsserviços” equivalente à edição de uma norma. O mesmo vale para a orientação a eventos. Este artigo verifica as referências técnicas disponíveis em 21/10/2026 e utiliza a RFC 9110 como referência para semântica HTTP, sem confundir a evolução do protocolo com a definição do estilo REST.

2. Para que serve cada abordagem?

A primeira pergunta é sobre organização: quais partes precisam mudar e ser implantadas com independência? A segunda é sobre interação: como clientes conhecem e manipulam recursos? A terceira é sobre reação: quais componentes precisam ser informados quando um fato ocorre? Separar essas perguntas evita transformar uma decisão de comunicação em resposta para todo o desenho do sistema.

Considere um serviço de notificações. Se ele precisa mudar frequentemente, uma implantação independente pode ser útil. Se recebe pedidos por uma interface HTTP, isso descreve seu mecanismo de interação. Se reage a eventos de outros sistemas, isso descreve outra forma de acionamento. Nenhuma dessas características, sozinha, prova que toda a organização possui uma arquitetura bem delimitada.

Os benefícios também dependem de capacidade operacional. Dividir uma aplicação em vinte componentes aumenta o número de implantações, configurações e pontos de observação. Uma equipe pequena pode obter mais previsibilidade com uma aplicação modular bem organizada. A escolha precisa responder a um problema real, e não apenas reproduzir um desenho considerado moderno.

3. Comparação com conceitos próximos

Em event sourcing, a sequência de eventos armazenados constitui a fonte de referência para reconstruir o estado. Esse padrão pode ajudar na análise histórica, mas traz complexidade de evolução e consulta. Já uma aplicação que atualiza uma tabela comum e publica uma notificação pode ser orientada a eventos sem usar event sourcing. Padrão Event Sourcing.

CQRS, de Command Query Responsibility Segregation, separa responsabilidades e modelos de leitura e escrita. A separação pode existir sobre um mesmo armazenamento; não exige, por definição, dois bancos físicos. Pode ser combinada com event sourcing, mas os conceitos não são equivalentes. Padrão CQRS.

Uma boa estratégia de estudo é perguntar: “O enunciado está descrevendo como dividir a aplicação, como conversar ou como guardar o histórico?” A resposta costuma esclarecer quais conceitos podem ser associados. Um sistema pode ter microsserviços, oferecer recursos por REST, divulgar eventos e ainda persistir seus dados com operações convencionais em tabelas.

4. Como funciona uma interação completa?

O fluxo abaixo é um exemplo didático de combinação das abordagens. Não existe obrigação de reproduzi-lo em toda aplicação.

1. Receber a solicitação. Um cliente envia os dados necessários ao serviço responsável. O resultado esperado é uma requisição validável, com identidade e conteúdo definidos.
2. Verificar as regras. O serviço confere autorização e condições de negócio. O resultado pode ser aceitação ou rejeição, com informação adequada ao cliente.
3. Registrar a mudança. A aplicação persiste a alteração de forma coerente com suas garantias locais. O resultado é um estado que pode ser consultado.
4. Comunicar o fato. Quando pertinente, publica-se um evento sobre a mudança concluída. O resultado é uma informação disponível aos interessados.
5. Reagir em outros componentes. Consumidores executam suas responsabilidades. O resultado pode ser uma notificação, uma projeção de consulta ou outro processamento.
6. Acompanhar falhas. A operação observa erros, atrasos e repetições. O resultado esperado é recuperar o processamento sem produzir efeitos indevidos.

Comunicação síncrona normalmente implica esperar a resposta da interação em andamento. Comunicação assíncrona permite que o trabalho continue em outro momento. Microsserviços podem usar ambas. A documentação da Microsoft distingue estilos de comunicação e mostra a combinação de interfaces com mensagens de integração. Comunicação em microsserviços.

Esperar uma resposta não é necessariamente um problema. Uma consulta curta pode se beneficiar de um resultado imediato. O risco aparece quando uma operação depende de uma longa cadeia de chamadas e o usuário fica sujeito à latência e às falhas de todos os participantes. O desenho deve considerar quais etapas realmente precisam terminar antes da resposta.

5. Elementos técnicos que exigem atenção

Recursos, representações e estado

Um recurso é algo identificável na interação, enquanto a representação é a forma usada para comunicar informações sobre ele. A solicitação de número 450 pode ser representada em JSON, por exemplo. REST não exige que o servidor deixe de armazenar dados. A restrição de ausência de estado refere-se à independência das requisições em relação a contexto de sessão guardado no servidor. Interface uniforme também envolve mensagens autodescritivas e hipermídia, não apenas nomes de URLs. Restrições de REST em Fielding.

Segurança e idempotência de métodos HTTP

Na RFC 9110, método seguro significa que a semântica solicitada é essencialmente de leitura. Idempotência significa que repetir requisições idênticas tem o mesmo efeito pretendido de uma só. GET é seguro e idempotente; PUT e DELETE são idempotentes, mas não seguros. POST não recebe garantia geral de idempotência. Isso não impede uma aplicação de criar proteção contra repetição para uma operação específica. RFC 9110: HTTP Semantics.

Imagine duas solicitações idênticas para remover um cadastro. A primeira pode removê-lo e a segunda informar que ele não existe. A diferença nas respostas não elimina a idempotência: o efeito pretendido continua sendo a ausência do cadastro. Também não se deve interpretar “seguro” como “criptografado” ou “livre de vulnerabilidades”; são propriedades distintas.

Comando, evento e confirmação

Um comando expressa uma intenção, como “Emitir certidão”. Um evento expressa um fato, como “Certidão emitida”. Se uma mensagem chamada “Certidão emitida” é enviada antes da conclusão, os consumidores podem agir sobre uma informação falsa. O nome deve corresponder à semântica e ao momento de publicação.

Confirmação de transporte ou recebimento também não equivale à conclusão do negócio. A documentação de confiabilidade do RabbitMQ distingue confirmações do publicador e reconhecimentos do consumidor. Falhas podem levar à retransmissão e a duplicidades. O consumidor precisa considerar sua responsabilidade antes de confirmar uma entrega. Guia de confiabilidade do RabbitMQ.

6. Abordagens para coordenação e consistência

Uma saga coordena uma sequência de transações locais, usando ações de compensação quando necessário. Pode ser organizada por orquestração, com um coordenador explícito, ou por coreografia, com reações entre participantes. Compensar não significa apagar fisicamente todos os efeitos como se nada tivesse acontecido. Uma comunicação enviada, por exemplo, pode exigir uma nova comunicação de correção. Padrão Saga.

O padrão transactional outbox trata o problema de atualizar um banco e publicar uma mensagem como duas operações sujeitas a falhas. Uma implementação registra a mudança e um item de saída na mesma transação local. Um processo posterior envia a mensagem. Ainda é necessário lidar com possíveis repetições no envio ou consumo. Transactional Outbox na documentação da AWS.

Consistência eventual não é autorização para dados incorretos permanecerem indefinidamente. O desenho precisa explicar como as partes convergem, como detectar atrasos e o que fazer quando o processamento não avança. Uma tela que mostra “processamento pendente” pode ser mais correta do que afirmar sucesso antes de todas as condições necessárias estarem satisfeitas.

Também é preciso especificar a unidade de ordenação. Talvez os eventos de uma mesma solicitação precisem ser processados na sequência correta, enquanto solicitações diferentes podem avançar independentemente. Exigir uma ordem global sem necessidade pode limitar o paralelismo. Em sentido oposto, ignorar uma dependência real pode fazer um consumidor aplicar uma etapa antes da anterior.

7. Exemplo completo: portal de licenças municipais

Cenário autoral. Um município recebe pedidos de licença para eventos. O cidadão envia os documentos, acompanha a análise e recebe comunicação sobre a decisão. A equipe identifica três responsabilidades: administrar solicitações, realizar análises e enviar notificações. A primeira versão será operada por uma equipe pequena, mas o volume de notificações é irregular e aumenta próximo a grandes eventos.

O problema principal é que uma falha no envio de e-mail impede a conclusão da recepção do pedido. O cidadão tenta novamente e, em alguns casos, cria solicitações duplicadas. Dividir todo o sistema em muitos serviços não é a primeira resposta. A equipe identifica que o envio de e-mail não precisa bloquear o registro do pedido.

A decisão inicial é manter o núcleo de solicitações e análises bem modularizado e separar o processamento de notificações. O portal registra o pedido e fornece um número de acompanhamento. A confirmação visual distingue “pedido recebido” de “licença concedida”. Essa diferença evita que um retorno técnico de sucesso seja interpretado como decisão administrativa favorável.

Após persistir o pedido, um evento informa seu recebimento. O componente de notificações prepara a mensagem ao cidadão. Se o provedor de e-mail estiver indisponível, o pedido continua registrado e o envio pode ser tentado novamente. A tela de consulta permanece disponível, de modo que o usuário não depende exclusivamente da mensagem para saber a situação.

A equipe usa um identificador de operação para reduzir duplicidade na recepção. Quando o cliente repete a mesma intenção devido a uma falha de conexão, o serviço verifica se a operação já foi registrada antes de criar outra solicitação. A regra precisa definir prazo de validade, escopo e comportamento em caso de conteúdo diferente com o mesmo identificador.

No consumidor, cada evento possui um identificador. Antes de executar um efeito que não deve se repetir, o processamento verifica seu histórico. A equipe decide quais repetições são aceitáveis e quais exigem controle mais forte. Uma atualização de projeção pode tolerar reaplicação, enquanto uma cobrança adicional não seria aceitável.

Outra falha precisa ser examinada: o pedido é salvo, mas o evento não é enviado. Para esse caso, o desenho usa uma saída persistente associada à transação local. A equipe monitora itens pendentes e tentativas com erro. Não presume que a presença de um broker resolve automaticamente o intervalo entre persistência e publicação.

Os dados do evento são limitados ao necessário. Não há motivo para publicar todos os documentos pessoais em um canal consumido por vários componentes. O serviço de notificações recebe as referências e informações adequadas à sua tarefa, com controles de acesso. A decisão de compartilhar dados faz parte do desenho, e não deve ser adiada para depois da integração.

O resultado esperado é receber pedidos mesmo durante indisponibilidade temporária do provedor de mensagens e reduzir duplicações. Ainda existem limitações: uma notificação pode atrasar, uma credencial pode expirar e uma mensagem malformada pode falhar repetidamente. O sistema precisa apresentar essas condições aos operadores e permitir tratamento controlado, sem esconder os erros em uma fila indefinida.

Para testar o comportamento, a equipe simula indisponibilidade do e-mail, reinício do consumidor, repetição de um evento e interrupção após o registro do pedido. Cada teste verifica uma hipótese específica. “Funcionou no caminho normal” é evidência insuficiente quando o objetivo da mudança é justamente suportar falhas.

8. Aplicação em pequenas equipes

Uma pequena organização pode começar com um monólito modular, ou seja, uma aplicação implantada como unidade, mas dividida internamente por responsabilidades claras. Isso permite aprender sobre fronteiras de domínio sem assumir imediatamente todos os custos de uma operação distribuída. A separação física pode ser feita quando houver um motivo concreto e capacidade de sustentá-la.

Um primeiro passo é documentar quem é responsável por cada dado e impedir alterações diretas por módulos sem autorização arquitetural. Outro é definir contratos claros para as interações internas. Essas práticas não transformam o monólito em microsserviços, mas ajudam a evitar acoplamentos que dificultariam uma evolução futura.

Se houver uma tarefa demorada, como gerar um relatório, a equipe pode introduzir processamento em segundo plano com acompanhamento de estado. O usuário recebe uma indicação de pendência e consulta o resultado depois. Antes de acrescentar uma nova tecnologia, vale verificar quais recursos já existem na plataforma utilizada e quais garantias realmente oferecem.

Uma rotina mínima de operação deve permitir responder: o trabalho foi recebido, está pendente, falhou ou terminou? Quem será avisado? É possível repetir sem duplicar o efeito? Essas perguntas são mais úteis do que começar pela escolha de uma marca de broker. Ferramentas gerenciadas podem reduzir esforço, mas não eliminam decisões de domínio.

O limite da simplificação aparece quando uma mesma equipe precisa controlar manualmente volume e complexidade que já excedem sua capacidade. Nesse momento, métricas de atraso, falha e carga ajudam a justificar a evolução. A arquitetura deve acompanhar necessidades observadas, sem converter crescimento futuro hipotético em complexidade imediata.

9. Revisão e exercícios comentados

Ao interpretar um enunciado, separe o que está afirmado do que você está supondo. A presença de contêineres não prova autonomia. O uso de HTTP não prova conformidade com REST. A existência de mensagens não informa, sozinha, se há entrega garantida, ordem global ou processamento exatamente uma vez.

Exercício autoral 1. Uma aplicação retorna JSON e usa apenas POST para consultar, alterar e excluir registros. É possível concluir que ela é REST? Não. O formato da representação e o protocolo de transporte não bastam para caracterizar as restrições do estilo. É preciso analisar a interface e a semântica das interações.

Exercício autoral 2. Um consumidor recebe duas vezes o evento “Pagamento confirmado”. A arquitetura necessariamente falhou? Não é possível concluir apenas pela repetição. Certas garantias de entrega admitem duplicidade. O problema será produzir um efeito indevido, como emitir duas cobranças ou executar duas concessões, se a operação deveria ocorrer uma única vez.

Exercício autoral 3. Cinco serviços precisam ser publicados juntos porque compartilham detalhes de implementação e mudanças de banco. Qual característica merece atenção? A independência de evolução está comprometida. Separação em processos ou repositórios não resolve, por si, dependências de contrato e de dados.

Exercício autoral 4. Uma aplicação publica eventos de atualização, mas consulta o estado atual em tabelas comuns e não o reconstrói a partir do histórico. Isso caracteriza event sourcing? Não. O exemplo descreve comunicação por eventos; falta a característica de usar os eventos persistidos como fonte de referência do estado.

Um exercício discursivo sobre decisão arquitetural

Considere a seguinte situação autoral: “Uma secretaria deseja separar o envio de notificações do recebimento de solicitações. Explique duas vantagens e dois cuidados dessa decisão”. Uma resposta adequada pode apresentar a redução da dependência imediata do provedor de mensagens e a possibilidade de processar a carga de notificações em ritmo próprio. Entre os cuidados, pode explicar como evitar perda entre registro e publicação e como tratar a repetição de mensagens.

Observe a diferença entre explicar e listar. Escrever apenas “escalabilidade, resiliência, idempotência e observabilidade” não demonstra o vínculo com o caso. A explicação deve mostrar que o pedido continua registrado durante uma falha do provedor, que a fila pode crescer e que alguém precisa perceber quando o atraso supera o aceitável. Os termos técnicos devem servir ao raciocínio.

Também é necessário reconhecer uma desvantagem: o cidadão pode receber a confirmação por e-mail depois de visualizar o protocolo na tela. A interface deve comunicar essa diferença de tempo. Se o requisito exigir que determinada etapa esteja concluída antes da resposta, não basta torná-la assíncrona e afirmar que o problema foi resolvido. A decisão arquitetural precisa respeitar o significado do serviço.

Como examinar uma promessa de processamento único

Quando um enunciado afirma “exatamente uma vez”, pergunte a que fronteira a garantia se aplica. Receber uma mensagem, atualizar um banco e enviar um e-mail são efeitos diferentes. Uma garantia oferecida por um componente não se estende automaticamente a todos os sistemas externos envolvidos.

No portal do exemplo, o consumidor pode concluir o envio de e-mail e falhar antes de registrar que terminou. Ao reiniciar, ele pode tentar novamente. A equipe precisa decidir como tratar essa janela, considerando o recurso oferecido pelo provedor e o impacto da duplicidade. Não há uma resposta única baseada apenas no nome do broker.

Esse raciocínio evita dois extremos: prometer que nenhuma repetição ocorrerá sem analisar as fronteiras ou aceitar qualquer duplicação como inevitável. O objetivo é identificar o efeito que precisa de proteção, desenhar o mecanismo correspondente e documentar a limitação que permanecer. Em prova, essa precisão costuma ser mais defensável do que uma afirmação absoluta desconectada do cenário.

10. Perguntas frequentes

Microsserviços, REST e eventos podem ser usados juntos?

Sim. Um conjunto de microsserviços pode oferecer interfaces orientadas a recursos e trocar eventos. Cada conceito descreve uma dimensão diferente da solução.

REST exige JSON?

Não. JSON é um formato possível de representação. A definição de REST depende das restrições arquiteturais, não da adoção obrigatória desse formato.

Uma arquitetura orientada a eventos elimina falhas?

Não. Ela muda a forma de lidar com dependências e processamento. Falhas de publicação, consumo, configuração e lógica continuam possíveis e precisam ser observadas.

Event sourcing e CQRS são obrigatórios em microsserviços?

Não. São padrões que podem ser úteis em certos contextos, mas introduzem escolhas e custos próprios. A adoção deve decorrer de necessidades identificadas.

Idempotência significa resposta sempre igual?

Não. O critério é o efeito pretendido da repetição. Uma nova resposta pode refletir que o resultado já foi alcançado anteriormente.

Um monólito pode ser uma boa decisão?

Sim. Uma aplicação modular e bem operada pode ser adequada à equipe e ao problema. O julgamento deve considerar requisitos, custos e capacidade de operação, não apenas o nome do estilo.

11. Conclusão

Microsserviços, REST e eventos ficam mais fáceis de entender quando você separa organização, interação e reação a fatos. Em seguida, acrescente as perguntas sobre persistência, consistência, repetição e falhas. Esse encadeamento ajuda a analisar tanto uma alternativa objetiva quanto um projeto real.

Para revisar, desenhe um fluxo simples e provoque uma falha em cada etapa. Explique o que o cliente vê, o que fica armazenado e como o processamento continua. Se você consegue responder sem presumir garantias inexistentes, está construindo uma compreensão arquitetural mais precisa.