Fluxo de publicação de produtos no catálogo

O time de catálogo é responsável entre outras coisas por disponibilizar informações relacionadas à produtos via API para serem consumidas posteriormente pelos canais de venda.

A ideia deste post é trazer um pouco da arquitetura e o fluxo de publicação de produto: desde a forma que um produto nasce até o momento em que é disponibilizado para o cliente final via canais de venda. Vale lembrar que no Magazine Luiza, vendemos produto da própria empresa (1P) e de outros vendedores que se conectam à nossa plataforma (3P).

Exemplo de produto publicado e sendo consumido pelo site do Magazine Luiza https://www.magazineluiza.com.br

Como temos mais de um milhão de produtos (com tendência a crescer) e consequentemente haver milhares de solicitações de criação/atualização/exclusão de produtos 1P/3P diariamente, podemos considerar então que seria uma abordagem problemática realizar todo esse processo de forma síncrona.

A demanda por escalabilidade seria exponencial devido ao grande volume de dados e quantidade de requisições geradas que um sistema síncrono teria que suportar e atender sob demanda! Além disso, haveria um forte acoplamento entre as muitas partes deste processo.

Por isso (como você verá aqui posteriormente) boa parte do nosso processo e arquitetura é feito de forma assíncrona: fazemos uso massivo de filas, eventos de stream e consumidores. Isso nos permite trabalhar de forma isolada em cada parte, escalando de forma muito mais eficiente. Também desacoplamos partes de todo o fluxo deste processo, segregando em diversos escopos.

Caso esteja interessado em entender um pouco mais sobre este tipo de arquitetura, sugiro um post escrito no próprio Medium do Luizalabs pelo dev Leonardo Mello Gaona: https://medium.com/luizalabs/desafogando-legados-com-streams-de-eventos-cc1d2299372f

Vale ressaltar que produtos 1P e 3P nascem de forma diferente, o que resulta terem fluxos distintos (ao menos no início), como você verá a seguir.

Nasce o produto 1P

Os produtos são cadastrados por meio de um sistema legado que o setor de multimídia utiliza. Nele estão contidos dados relevantes para um produto, tais como:

• Título
• Descrição
• Imagens
• Ficha Técnica

Exemplo Ficha Técnica de um produto

Porém, lembre-se: Isso é um sistema legado! Esses dados são cadastrados, mas ainda não entraram no fluxo de publicação/atualização. O mesmo só dá início quando os pollers obterem estes dados. Mas o que são esses pollers?

Pollers

Os pollers são processos que sabem conversar com sistemas para obter todos os dados referentes à produtos de tempos em tempos. Estes dados são tratados de acordo com algumas regras definidas e então enviados para um serviço de stream.

Podemos também enviar essas informações em lotes (ou seja, “pacotes” de produtos) para o stream, o que torna este processo ainda mais eficiente: são necessários menos requisições para enviar produtos para o serviço.

Então, resumidamente, o que vimos do fluxo até agora?

• Um produto foi cadastrado com todas as suas informações em um sistema legado pelo time de multimídia;
• O Poller obteve e tratou dados de produtos e enviou para um serviço de stream

Fluxo: Poller obtém dados de produtos do sistema legado e envia para o serviço de stream

Nasce o produto 3P

Vamos voltar um pouco o fluxo e entender agora como nasce um produto 3P. O fluxo é um pouco diferente do nascimento de produtos 1P.

Relembrando: produtos 3P são provenientes de outros vendedores que utilizam toda a infraestrutura oferecida pelo Magazine Luiza para publicar e vender produtos em nossos canais.

Temos uma API que permite que vendedores publiquem seus produtos, bastando respeitar o formato que aceitamos receber estes dados.

Ao receber estes dados são realizadas diversas validações envolvendo características que consideramos importantes que um produto deve ter para ser publicado, até que o produto é enviado para o stream.

Vale lembrar que parte do processo antes do envio para o stream é feito de forma assíncrona por meio de filas. Assim, apartamos algumas tarefas que exigem mais processamento e tempo antes dos produtos serem endereçados.

Fluxo: Produto é enviado para o integrador de Marketplace para vendedores e enviado para o serviço de stream

Consumidores de Stream

Como você pode ter imaginado, o serviço de stream é o local de encontro de produtos 1P e 3P. A partir de agora então, os produtos estão no mesmo fluxo.

Estes consumidores obtém os dados referentes à produtos. A ideia principal destes consumidores no fluxo é deixar os produtos prontos para a API de produtos (catálogo) disponibilizar para os canais que quiserem consumir.

São realizados diversos processos tais como: validações, indexação para busca, envio de informações para buckets dentre outros. Cada consumidor em geral tem um escopo específico dentro do fluxo. Isso resulta em um fraco acoplamento entre as partes, conforme foi mencionado anteriormente.

Entrando mais a fundo nos processos que estes consumidores fazem, valem ressaltar dois principais: o matching e o buybox.

Consumidores: Obtém dados dos streams e realizam todos os processos necessários para a disponibilização de produtos no catálogo

Matching

Como temos uma base de produtos consideravelmente grande, existem casos que um produto é praticamente igual ao outro, diferindo em apenas alguns poucos atributos.

Por exemplo, imagine que exista uma lavadora da marca X, com capacidade de seis litros, com voltagem é 220 volts. (Vamos considerar que essas sejam as únicas informações relevantes deste produto).

No entanto, foi publicada uma lavadora com mesmo título, da marca X, com capacidade de seis litros, porém sua voltagem é 110 volts.

Conseguiu notar algo? Sim, as lavadoras são quase idênticas! Com exceção de uma variação (voltagem).

Podemos ter duas abordagens:

• Dois produtos diferentes no catálogo;
• Um único produto agrupado contendo duas variações;

Neste caso, faz muito mais sentido se tornarem um mesmo produto e terem duas variações por uma característica (no exemplo acima, seria voltagem).

Sem o processo de matching, haveriam muitos produtos duplicados apenas por conta de alguns atributos.

Trabalhamos apenas um exemplo, mas com centenas de vendedores publicando variados produtos, é inevitável que ocorram casos assim.

Exemplo de caso de matching no site: Apenas a voltagem varia nestes casos.Se houvesse o matching, haveriam seis lavadoras diferentes listadas, variando apenas a voltagem.

Buybox

Como já mencionado neste post, diversos vendedores estão conectados à nossa plataforma e podem publicar N produtos.

Também podem ocorrer casos que dois ou mais vendedores publiquem uma oferta para um mesmo produto em nosso catálogo. Porém, da mesma forma que no matching, apresentar essas ofertas de forma separada não é uma experiência interessante para o usuário final, pois as ofertas apareciam separadamente em uma busca.

No processo de buybox, agrupamos essas ofertas de forma a ser exibido em um único produto. É muito similar com o processo de matching, porém neste caso objetivo é diferente: não queremos agrupar produtos similares e sim ofertas de diferentes vendedores em um mesmo produto!

Neste agrupamento, também temos algumas regras e características que consideramos para cada oferta de vendedor para especificar quem será a primeira a ser exibida para o usuário. Em outras palavras: quem é o vencedor do buybox.

Este processo é importante, pois o vencedor do buybox será a oferta principal exibida para o usuário: isso aumenta significamente as chances do item ser comprado pelo cliente.

Exemplo de produto buybox: O vencedor neste caso é o Magazine Luiza. Outras ofertas de vendedores encontram-se logo abaixo

Disponibilização do produto para os canais

Uma vez que o produto é enviado para a API REST, os produtos são finalmente publicados e estão prontos para serem consumidos pelos nossos canais.

Produtos disponibilizados para os canais digitais consumirem

Enfim, essa é a jornada para um produto ser publicado para vendas em nossos diversos canais. Muito obrigado e até a próxima!