A arquitetura orientada a eventos está se transformando de um modelo limitado entre poucos serviços em uma ampla rede de produtores, consumidores e canais de mensagens. Nesse ponto, o problema principal já não é enviar a mensagem, mas saber o que é enviado, quem é seu proprietário, quem depende dela e como seu esquema pode ser alterado ou sua infraestrutura recriada sem causar falhas em produção. Esse é o foco da sessão de Ian Cooper sobre o gerenciamento de APIs assíncronas em larga escala, com base em práticas de engenharia reais na Just Eat Takeaway.
Por que a situação se torna complexa com a expansão?
Em organizações pequenas, os membros das equipes podem conhecer os serviços que publicam e consomem eventos, e os tópicos ou canais podem ser criados por meio da estrutura de mensagens ou mediante uma solicitação direta à equipe da plataforma. No entanto, essa abordagem perde eficácia à medida que aumenta o número de equipes e serviços. Pode não estar claro quem é o proprietário de determinado endpoint, qual contrato descreve a mensagem ou se existem consumidores desconhecidos nas equipes de dados e análise.
O risco surge quando uma equipe altera o esquema de uma mensagem após consultar apenas os consumidores conhecidos, enquanto outras equipes dependem da mensagem sem fazer parte do círculo de comunicação. A exclusão de um tópico considerado não utilizado pode levar à perda de um fluxo crítico, especialmente se não houver uma forma confiável de saber quem é seu proprietário ou de recriar a infraestrutura necessária, além de republicar grandes partes do sistema.
Três eixos para o gerenciamento de interfaces de eventos
Cooper divide o problema em descoberta, governança e provisionamento. Isso começa com a compreensão do que deve ser descrito em qualquer endpoint por meio do que ele chama de «ABCs»: endereço, binding e contrato. O endereço determina onde as mensagens fluem, o binding descreve o protocolo, o transporte e a codificação, enquanto o contrato determina os cabeçalhos e os dados transportados pela mensagem.
Nesse contexto, a AsyncAPI oferece um equivalente aos mecanismos de documentação de interfaces HTTP, como o OpenAPI, com modelagem de servidores, canais, mensagens, operações e bindings específicos do protocolo. Ela oferece suporte à descrição de mensagens usando JSON Schema, Avro e Protobuf, além de permitir a reutilização de definições em vez de repeti-las em vários arquivos. No entanto, Cooper enfatiza que colocar centenas de arquivos AsyncAPI em um único repositório não resolve a descoberta por si só; a pesquisa textual continua limitada quando o inventário de eventos cresce.
Por isso, as organizações podem precisar de ferramentas de catálogo, como EventCatalog ou Marmot, ou de um registro aberto, como o xRegistry, com o objetivo de exibir os fluxos de mensagens e as relações entre eles e vincular os esquemas aos produtores e consumidores. Essas ferramentas diferem no nível de visualização e nas interfaces prontas, mas sua função comum é transferir a descoberta de uma pergunta feita no Slack ou de uma busca em repositórios dispersos para um serviço consultável.
O papel do CloudEvents na padronização dos metadados
O CloudEvents aborda uma parte diferente do problema, fornecendo um conjunto padronizado de metadados, como identificador, origem, versão e tipo, além de campos opcionais para o tipo de conteúdo dos dados, o assunto, o horário e um link para o esquema. O tipo do evento pode ser usado para encaminhar a mensagem ou escolher o mecanismo de desserialização quando vários tipos compartilham um único canal.
A sessão explica que os modos binary e structured do CloudEvents estão relacionados à capacidade do protocolo de transporte de carregar cabeçalhos, e não ao fato de a mensagem ser «binária» ou «estruturada» no sentido habitual. Esse detalhe é importante em sistemas como o SNS, nos quais um número limitado de atributos da mensagem pode ser consumido rapidamente se todos os dados do CloudEvents forem colocados nos cabeçalhos, tornando o encapsulamento no corpo uma opção prática em alguns cenários.
A governança não se limita à documentação
A documentação do contrato informa aos consumidores o que é a mensagem, mas não impede o produtor de publicar uma alteração que quebre suas dependências. Por isso, a abordagem apresentada recomenda o uso de um registro de esquemas que aplique regras de compatibilidade ao atualizar os contratos e rejeite mensagens ou alterações que não estejam de acordo com as regras aprovadas.
As práticas seguras normalmente incluem adicionar campos como opcionais, adiar a remoção de campos até que todos os consumidores deixem de utilizá-los e tratar a renomeação como uma alteração composta por remoção e adição. Já a alteração do tipo de um campo geralmente é considerada uma alteração incompatível e pode ser implementada adicionando um novo campo com o tipo desejado, migrando os consumidores para ele e removendo o campo antigo posteriormente.
O que muda na prática?
A mensagem principal para o leitor técnico é que o gerenciamento de eventos em larga escala precisa de uma cadeia integrada, não de uma ferramenta isolada: AsyncAPI para descrever as interfaces, CloudEvents para padronizar os metadados, um catálogo ou registro para facilitar a descoberta, um registro de esquemas para impor a compatibilidade e automação para provisionar a infraestrutura e monitorar sua divergência. Sem essas camadas, a arquitetura orientada a eventos pode se transformar em uma rede de dependências invisíveis.
Continuam existindo limitações práticas: os padrões, por si só, não oferecem conhecimento completo sobre os consumidores, e as ferramentas diferem no suporte a interfaces, visualização e integração com os brokers. Por isso, a aplicação dessa abordagem exige definir claramente a propriedade dos contratos e canais, vincular as alterações aos processos de CI/CD e manter um caminho de recuperação capaz de recriar os recursos, em vez de depender de conhecimento individual ou de documentação desatualizada.