Como transformei um componente do legado em um serviço de alta performance, resiliente e escalável — Tiago Tartari

Em sistemas legados, adaptar aplicações para atender determinadas demandas de negócio muitas vezes torna-se inviável. Na prática, estamos falando de eventuais perdas de confiabilidade, riscos à operação, como por exemplo indisponibilidade.

Esse post foi originalmente escrito em meu blog.

Como transformei um componente do legado em um serviço de alta performance, resiliente e escalável…

Nesse sentido, vamos ver na prática a abstração da leitura de um serviço de estoque, transformando em um serviço de alta performance, resiliente, escalável sem trazer riscos para o legado.

Em um e-commerce, o estoque é um dos aspectos mais importantes. Logo, se os produtos estão disponíveis, temos a possibilidade de aumentar as vendas. Por certo, ofertar aquilo que não vamos entregar gera um experiência muito ruim para seus clientes, além de perder o engajamento das campanhas até então feitas e o pior, gerar riscos irreparáveis à imagem da sua loja.

Eventos como Black Friday exigem ainda mais do estoque, de tal modo que a defasagem pode prejudicar as vendas. Semelhantemente, devido ao elevado número de acessos, não ter uma aplicação escalável, coloca, inclusive, toda estratégia de marketing em risco.

Especificamente na Black Friday há um número elevado de transações de escrita e leitura no banco de dados, portanto, você precisa de escala.

Como um e-commerce é basicamente dividido?

Na imagem abaixo demonstro como um e-commerce é dividido seguindo a jornada do cliente já dentro de uma loja virtual.

Quais são as restrições para esse serviço?Ao falarmos de estoque, podemos perceber que ele está presente em praticamente toda as etapas da jornada do cliente na loja virtual, entretanto, para cada área há um tipo de restrição que deve ser considerado no momento da abstração e principalmente no momento em que precisamos tornar nossa API escalável e performática.

Sempre ao lidarmos com alta demanda de acessos, inevitavelmente, precisamos entender as restrições a cerca desse serviço, inclusive, faz parte das práticas da SRE, do mesmo modo precisamos entender quais as restrições são impostas pela área de negócio.

Dica: Com base nas restrições de negócios, temos indícios claros de quais SLOs, Service Level Objectives, serão criados, uma vez que esses indícios revelam o ponto de atenção e cuidados a serem tomados.

Na imagem acima, para cada etapa existe uma ou mais restrições, de forma básica e prática vou listar algumas delas. Lembre-se que as restrições são baseadas naquelas que o negócio pode impor.

1. Produtos indisponíveis devem ficar no final da lista;
2. Um selo de indisponibilidade deve ser colocado quando um SKU está indisponível nas telas de listagem de produtos e página de produto;
3. Um produto sem estoque não pode ficar mais que 5 minutos informando disponibilidade;

A percepção do cliente a cerca da disponibilidade do estoque acentua o nível de necessidade daquele produto, portanto o serviço deve ter:

1. 98% das solicitações de estoque devem ser respondidas abaixo de 30ms;
2. 99% das solicitações de estoque devem ser respondidas sem erros;

AS-IS

Por se tratar de um sistema legado, temos um sistema altamente acoplado, qualquer alteração que seja feita nele podemos colocar em risco toda a operação, além disso, a eminência de bugs pode ser alta. O fato de ser um legado a arquitetura não permite um nível aceitável de escalabilidade e também não atende as restrições impostas por negócios.

TO-BE

Na prática, estamos separando toda leitura do estoque para um novo serviço. Não fizemos alterações no legado, uma vez que qualquer alteração poderia colocar em risco a operação.

O que fizemos em ordem para separar a leitura do legado e com isso criar um serviço de alta performance.

1. Habilitamos o Change Data Capture no SQL Server.
2. Utilizamos o Debezium + Kafka Connect + Kafka para ler o banco de dados com as informações capturadas pelo CDC
3. Inserimos o Apache NiFi para ler o tópico do Kafka, passar por algumas transformações e:
4. Inserir no Banco de Dados noSQL os dados transformados de estoque;
5. Apagar a chave de cache no Redis;
6. Consumir uma API de leitura para incluir o novo resultado no Redis.
7. Criamos em nossa cloud toda a infra para suportar a alta demanda, inclusive com autoescalonamento.
8. Criamos uma API com único endpoint onde o resultado trás se o produto / sku está ou não disponível.

De forma simples, entretanto, específica e direta abaixo temos o desenho do TO-BE.

Conclusão

Nesse post, podemos perceber que das decisões de arquitetura também estão relacionadas as restrições de negócio, inclusive pude perceber, na prática, que um não pode estar desassociado do outro.

Também pudemos perceber que muitas vezes para atingir um certo objetivo precisamos “Separar para crescer”, o que na prática é: Não fique fechado no âmbito do seu legado. Objetivos como esse são oportunidades para estrangulamento do legado.

Originally published at https://www.tiagotartari.net on January 14, 2021.