bom pessoal e agora a gente vai falar de algo assim não é importante é muito importante tá que é chamado de esquema evolutivo porque eu estou dizendo isso pessoal todas as vezes está que a gente vai trabalhar com esses eventos ou que a gente vai fazer com que a gente tem um publicador numa ponta e um consumidor nessa outra ponta você vai ter algo extremamente simples mas que pode virar um caos na sua aplicação que é o que é o esquema da mensagem tá vamos olhar aqui ó a gente tem por exemplo essa mensagem aqui onde eu falo Order ID é 1, status aprovado, Product ID é 1 e etc. O sistema que publica sabe que ele tem que mandar essa mensagem nesse formato. Mas o sistema que lê, ele também tem que saber que a mensagem está nesse formato. O que acontece caso, por exemplo, esse sistema estivesse sempre mandando a mensagem com o produto de online id e daí simplesmente de um dia para o outro ele fizesse assim ó mandasse produtividade sem o underline o que queria acontecer o sistema que fosse ler essa mensagem não ia achar o Product Underline ID, não ia reconhecer o Product ID e daí o que ia acontecer? Ia dar muito problema. O grande ponto é que conforme o tempo passa, os sistemas mudam, os dados mudam e o esquema de publicação de uma mensagem muda também. Agora, vamos imaginar que eu tenho 10 microserviços lendo um microserviço que está mandando uma mensagem. Já pensou se esse microserviço começa a mandar a mensagem em um formato diferente e aqueles 10 microserviços começam a quebrar. Então, a gente precisa ter uma meio de reenforçar o padrão de envio e recebimento das mensagens, desses eventos. E a forma que a gente faz isso normalmente tá se eu voltar isso normal é através de esquemas ou seja você chega para o consumidor e para o publicador e define o esquema de envio de mensagens na e recebimento é esse aqui e todo mundo vai seguir o grande ponto é que quando esse esquema precisa mudar a gente precisa ter técnicas e mecanismos que a gente mantém a compatibilidade desses esquemas e existem algumas formas de manter essa compatibilidade então vamos falar sobre os três tipos básicos para você conseguir evoluir o esquema quando o seu sistema precisa ter essas mudanças de padrão. Então vamos lá. A gente tem o primeiro formato que é chamado de Forward Compatibility. O que isso faz? Os dados, eles são produzidos com um novo esquema, mas ainda mantém a compatibilidade de leitura com o esquema antigo, tá? Ou seja, não há alteração de código pelo consumidor. Então, vamos imaginar que eu tenho o sistema 1, ele manda a informação e o sistema 2 consegue ler Aí o sistema 1 ele muda o padrão de mandar a informação Mas o padrão que ele manda a informação não quebra o sistema que está lendo Mas ele começa a trazer, a enviar novos dados Então isso aí é bem interessante. Então, isso é chamado de Forward Compatibility. Aí, a gente tem um outro formato de você conseguir trazer essas informações, que é chamado de Backward Compatibility. O que significa? Que o dado que é produzido em um esquema antigo pode ser lido como se fosse um novo esquema. Como assim? Vamos imaginar que eu tenho um consumidor. E esse consumidor está criando uma nova feature. Como assim? Vamos imaginar que todas as vezes que agora um cartão de crédito for aprovado, a gente vai colocar R$100 na conta da pessoa, ou um valor X na conta. com antecedência, falando, olha gente, vai entrar uma nova feature daqui 15 dias e a gente vai começar a mandar um campo para vocês chamado bônus. E então, toda vez que tiver esse campo bônus, você já adiciona como crédito ali para a pessoa. Beleza. Mas o que acontece? O consumidor conseguiu resolver esse problema com 10 dias de antecedência. Ou seja, se o consumidor quiser agora colocar isso em produção, ele consegue colocar em produção, mesmo que o produtor ainda não esteja enviando essa mensagem. Então, isso vai ajudar bastante no trabalho ali no dia a dia. Então, olha só que interessante que a gente consegue trabalhar. Ou seja, o consumidor consegue implementar uma nova feature mesmo antes dessa feature dos dados serem enviados ali para ele. Uma coisa interessante também é que quando você trabalha com backward compatibility, mesmo que você vá ler, que você fosse trabalhar com event sourcing e as mensagens estivessem no padrão antigo, ainda assim você iria conseguir ler. Então, isso aí é importante. Ainda assim você iria conseguir ler. Então isso aí é importante. Agora, a gente tem um outro formato, que é o terceiro formato, que é chamado de Full Compatibility. É a combinação dos dois mundos. Ele faz com que os esquemas antigos consigam ser processados, que você consiga prever as novas mudanças do esquema ao mesmo tempo. É muito difícil você conseguir fazer isso. Você tem que ter muito planejamento para você conseguir trabalhar. Mas é possível, mas nem sempre isso é necessário. Porque você vai gastar um bom tempo de planejamento para você conseguir trabalhar dessa forma, tá? Mas de qualquer jeito, tá? Existem essas três formas de você conseguir trabalhar. Bacana? Então, estão aí o nosso esquema evolutivo.