Imagine um grande varejista online com vários sistemas que geram e consomem dados: um site de e-commerce, um aplicativo móvel, um mecanismo de recomendação, um sistema de gestão de estoque, uma plataforma de logística e uma plataforma de análise de clientes. Cada um desses sistemas se comunica publicando e consumindo eventos em clusters do Apache Kafka no Confluent Cloud e, no pipeline de dados, transmite esses eventos a um data warehouse por meio do Kafka Connect.
Toda ação no site gera vários eventos nos sistemas do varejista. Sempre que um cliente faz um pedido, o site publica um evento OrderCreated
em um tópico do Kafka.
Várias aplicações consomem esse mesmo evento. O sistema de estoque reserva os itens comprados, o sistema de pagamento confirma a transação e o armazém inicia a separação e o envio do pedido. O mecanismo de recomendação atualiza as preferências do comprador, a plataforma de análise contabiliza a venda e o serviço de notificação ao cliente envia uma confirmação por e-mail.
De início, o evento OrderCreated
contém campos como order_id
, customer_id
, product_id
, quantity
e total_price
. Todas as aplicações consumidoras foram desenvolvidas para trabalhar com essa estrutura.
Agora imagine que, meses depois, a empresa decide começar a vender para o exterior. Os desenvolvedores atualizam o site para que cada pedido passe a incluir dois campos novos: currency
e exchange_rate
.
Sem um registro de esquemas, não há um mecanismo centralizado para coordenar essa alteração. Alguns consumidores de dados de eventos esperam os campos novos, e outros não. Se um desenvolvedor renomear por engano o campo total_price
para order_total
ou mudar o tipo de dado desse campo de decimal para string, os serviços que dependem do evento podem começar a falhar de forma inesperada. O armazém pode deixar de receber pedidos, os dashboards de análise podem gerar relatórios incorretos ou as notificações aos clientes podem falhar por não conseguirem interpretar o evento.
Como ficaria, então, esse mesmo cenário com o Confluent Schema Registry para ajudar no gerenciamento de esquemas?
Antes de implementar o produtor atualizado, a equipe de desenvolvimento registra uma nova versão do esquema OrderCreated
. Essa etapa gera um novo ID do esquema, associado a essa versão. O registro de esquemas compara as alterações propostas com as configurações de compatibilidade da organização.
Se as mudanças atenderem a essas regras de compatibilidade, a nova versão do esquema pode ser registrada. Se uma alteração violar a política de compatibilidade configurada, o registro pode recusar essa mudança antes que as aplicações comecem a usar o esquema incompatível.
Isso significa que os desenvolvedores podem identificar uma alteração de esquema incompatível durante o desenvolvimento, e não depois da implementação. Os consumidores atuais podem continuar funcionando com as alterações compatíveis, enquanto as equipes de desenvolvimento atualizam aos poucos as aplicações para usar os campos novos quando estiverem prontas.