Criar pedidos modernos e omnichannel no MongoDB

Visão Geral da Solução

Hoje em dia, os clientes esperam experiências de compras perfeitas que combinem canais online e offline. No entanto, varejistas enfrentam dificuldades para implementar essas soluções omnichannel que proporcionam experiências consistentes em todos os pontos de contato.

A oferta de opções convenientes como Compre online, retire na loja (Buy Online, Pick Up In Store, BOPIS) e Compre online, receba em casa é essencial para permanecer competitivo, mas a implementação de uma estratégia omnichannel impõe desafios técnicos. Os varejistas precisam de um sistema flexível que ofereça visibilidade em tempo real, lide com padrões de tráfego dinâmicos e possibilite integrações modernas em todos os pontos de contato com o cliente.

Esta solução demonstra como criar um website de e-commerce omnichannel usando o MongoDB Atlas. A demonstração apresenta uma jornada do cliente em que os usuários podem escolher um método de envio (retirada na loja ou entrega em domicílio) e monitorar o pedido em tempo real até a entrega. Ao utilizar os principais recursos do MongoDB, incluindo o Change Streams, o Atlas Triggers e o document model flexível, você aprenderá como criar um sistema de pedidos omnichannel robusto e dimensionável.

Arquiteturas de referência

O principal desta solução é utilizar o Change Streams e Atlas Triggers do MongoDB para habilitar operações de dados em tempo real em vários aplicativos. A arquitetura é composta por dois componentes principais: os apps em tempo real e o MongoDB Atlas.

O lado dos aplicativos em tempo real inclui qualquer aplicativo que responda a alterações no banco de dados, como aplicativos de e-commerce, centro de distribuição, armazém e inventário.

No MongoDB Atlas, o fluxo de trabalho é o seguinte:

1. Uma ação produz uma modificação de dados, por exemplo, uma atualização do status do pedido.

2. O evento é registrado na coleção Pedidos.

3. Essas alterações são registradas no log de operações (oplog.rs).

4. A API Change Streams monitora essas alterações.

5. Com base nas suas necessidades de arquitetura, você pode escolher:

   • Executar a atualização do lado do aplicativo.

   • Acione uma tarefa automatizada por meio das funções do Atlas.

Além da nossa implementação atual, essa arquitetura fornece uma base para vários cenários em tempo real, tais como:

• Notificações em tempo real: alertas automáticos para os clientes informando quando os pedidos estão disponíveis para retirada.

• Sistemas reativos: gerenciamento inteligente de estoque com reabastecimento automático.

• Arquitetura orientada a eventos: sincronização de microsserviços em tempo real com integração opcional ao Kafka.

• Captura de alterações de dados: atualização imediata de preços de produtos em todo o sistema.

• Análise em tempo real: recálculo instantâneo de risco de fraude usando modelos de ML.

Figura 1. As modificações no banco de dados são registradas no oplog como eventos. A API do Change Streams monitora alterações, detecta eventos observados e aciona respostas em tempo real nos aplicativos ou no Atlas Triggers

A simplicidade deste processo vem do recurso de replicação do MongoDB e do log de operações subjacente (oplog), que registra todas as mudanças ao banco de dados. Esse mecanismo permite que os Change Streams enviem atualizações de forma eficiente para o seu aplicativo sem adicionar camadas adicionais ou complexidade. A replicação garante principalmente alta disponibilidade ao manter múltiplas cópias de dados entre os nós e possibilita atualizações em tempo real. Os aplicativos podem monitorar alterações em diferentes escopos (coleção, banco de dados ou em todo o cluster) e filtrar alterações específicas usando o framework de agregação.

Abordagem do modelo de dados

Quando um desenvolvedor escreve um algoritmo, a complexidade não precisa vir acompanhada de complicação. Mais linhas de código nem sempre resultam em uma solução melhor. A chave é a simplicidade. Soluções simples são mais fáceis de entender e mais rápidas de implementar, permitindo que você se concentre no que realmente importa: inovação.

O modelo de dados da nossa solução gira em torno de duas coleções primárias: produtos e pedidos. Cada coleção usa o formato campo : valor, o que fornece uma representação organizada dos dados armazenados. Vamos analisar como cada coleção é estruturada.

Coleção "produtos"

• Armazena informações abrangentes do produto, incluindo ID, nome e um identificador exclusivo do produto (como SKUs).

• Contém campos de categorização (masterCategory, subCategory, articleType).

• Apresenta objetos aninhados para precificação com campos de valor e moeda.

• Inclui atributos específicos do produto, como status de reabastecimento automático e cor principal.

• Mantém campos relacionados ao inventário e metadados de produtos.

Figura 2. Documentos do MongoDB da coleção "products"

Coleção "pedidos"

• Acompanha os detalhes dos pedidos com identificadores exclusivos para pedidos e usuários.

• Contém um array de produtos para cada pedido.

• Apresenta uma array "status_history" que captura a progressão dos status dos pedidos com data e hora.

• Diferencia entre os tipos de pedidos (compra online com retirada na loja versus compra online com entrega em domicílio).

• Armazena endereços de envio específicos para cada pedido.

• Adapta fluxos de trabalho de status com base no tipo de entrega:

  • Os pedidos para retirada na loja exibem status como Em processamento → Pronto para retirada.

  • Os pedidos com entrega em domicílio passam por estados como Em processamento → Pronto para entrega → Retirado do armazém → Em trânsito → Entregue.

O valor desse modelo está na sua flexibilidade. Ao possibilitar que a estrutura de dados evolua com o fluxo de trabalho do usuário, o modelo permite que a empresa se adapte facilmente às necessidades atuais e aos desafios futuros que possam surgir. Por exemplo, um documento de produto do MongoDB inclui um campo chamado preço, que contém uma array de valores que permite representação em várias moedas, como USD 12.

Figura 3. Documentos do MongoDB da coleção de pedidos

Construindo a Solução

A construção desta solução pode ser dividida em três etapas principais.

Para obter informações completas sobre implementação, incluindo exemplos de código, arquivos de configuração e tutoriais em vídeo, acesse o repositório do GitHub.

Principais Aprendizados

Essa solução demonstra três funcionalidades principais do MongoDB que o tornam adequado para aplicativos de varejo omnichannel:

• Flexibilidade e velocidade: o document model flexível do MongoDB não é apenas intuitivo para desenvolvedores, mas também fácil de implementar e executar. Essa flexibilidade permite que as empresas se adaptem rapidamente às mudanças ao garantir que suas soluções evoluam com facilidade. Como resultado, os desenvolvedores podem se concentrar em criar soluções em vez de lidar com estruturas de dados complexas, o que resulta em agilidade do lançamento no mercado e uma experiência omnichannel consistente.

• Funcionalidades em tempo real: recursos como o Change Streams e o Atlas Triggers melhoram as interações com os clientes através do processamento de dados dinâmico e em tempo real, essencial para tarefas como monitoramento de pedidos e atualizações de estoque.

• Arquitetura inteligente: a alta disponibilidade e a arquitetura dimensionável do MongoDB fornecem uma base sólida para oferecer experiências interconectadas ao cliente, essenciais na era omnichannel. Ferramentas como o Change Streams e o Atlas Triggers podem ser facilmente integradas ao seu aplicativo sem uma camada adicional, simplificando a implementação dessas mudanças graças à arquitetura subjacente do MongoDB.

Cada uma dessas funcionalidades contribui para a construção de um sistema de pedidos omnichannel robusto que pode ser dimensionado conforme as necessidades do seu negócio, mantendo o desempenho e a confiabilidade.

Tecnologias e produtos utilizados

Autor(a)

• Angie Guemes, MongoDB

• Florencia Arin, MongoDB