Por Mike Gomez, Technical Account Manager na Amazon Web Services (AWS); Salman Ahmed, Senior Technical Account Manager na Amazon Web Services (AWS) e Sunaina Karve, Senior Technical Account Manager na Amazon Web Services (AWS).

Integrando agregadores e restaurantes de serviço rápido com arquiteturas Serverless da AWS

Nesta postagem, você aprenderá a usar as tecnologias Serverless da AWS, como Amazon EventBridge e AWS Lambda, para criar uma integração entre restaurantes de serviço rápido (QSRs) e agregadores on-line de pedidos e entrega de alimentos. Esses agregadores surgiram como uma opção para os QSRs expandirem sua base de consumidores, oferecendo opções de entrega para ajudar a expandir seus negócios.

Visão geral do QSR

Os QSRs priorizam um serviço rápido e conveniente, oferecendo um menu simplificado. Para atender às crescentes expectativas dos consumidores, os QSRs podem usar integrações de API com agregadores terceirizados. Essa sinergia tecnológica permite que os QSRs expandam suas capacidades, introduzindo diversos métodos de pagamento e incorporando serviços de entrega. Esses recursos se tornaram padrão nesse segmento de restaurantes.

Nos bastidores, as APIs são usadas para orquestrar a interação entre o agregador e o QSR e, ao mesmo tempo, ter uma experiência consistente de pedidos e entrega.

Os objetivos de negócios do QSR são:

• Proporcionar experiências consistentes de pedidos e entregas
• Oferecer itens de menu personalizados
• Manter clientes recorrentes
• Reduzir o cancelamento de entrega por terceiros devido à falta de opções de personalização da entrega

Esta postagem começa com uma arquitetura simples e adiciona componentes para resolver desafios arquitetônicos.

Arquitetura

Como arquiteto de soluções, você foi abordado por uma próspera empresa local de restaurantes que busca soluções tecnológicas para impulsionar sua expansão. Sua tarefa é projetar uma arquitetura de integração ideal que se alinhe aos requisitos técnicos, simplifique as operações e aprimore a experiência do cliente.

No centro dessa integração está o Amazon API Gateway, que aceita os pedidos recebidos de vários agregadores de entrega. O API Gateway se torna a porta de entrada, conectando os QSRs aos clientes finais para um sistema de processamento de pedidos simplificado e dinâmico.

Impulsionando o back-end dessa integração estão as funções do Lambda. Essas funções validam os pedidos e se comunicam com segurança com os agregadores de entrega. As funções do Lambda podem ser escaladas dinamicamente com base na demanda e garantir o uso ideal dos recursos e a economia.

Fluxo de trabalho de realização de pedidos

As etapas a seguir descrevem a integração Serverless entre o API Gateway e as funções do Lambda, conforme mostrado na figura a seguir:

• Os clientes podem fazer pedidos por meio de agregadores de entrega de alimentos ou do próprio sistema de pedidos da empresa.
• A solicitação do pedido é enviada ao API Gateway.

Essa arquitetura funciona para integrações pequenas e simples. Para escalar essa arquitetura para alto tráfego, use a integração assíncrona para reduzir o acoplamento entre a API e a função Lambda.

Fluxo de trabalho de roteamento de pedidos

As etapas a seguir descrevem uma integração Serverless em que o API Gateway se conecta às funções do Lambda por meio do Amazon EventBridge como serviço de roteamento de eventos, conforme mostrado na figura a seguir:

1. O API Gateway recebe a solicitação do pedido.
2. O API Gateway encaminha a solicitação de pedido do cliente para um barramento EventBridge para processamento.

O EventBridge direciona eventos (por exemplo, mudanças no status do pedido) para as funções do Lambda, garantindo a resiliência durante interrupções no serviço. Isso elimina o tratamento manual de erros e mantém os QSRs e agregadores sincronizados.

O EventBridge oferece os seguintes recursos essenciais:

• O EventBridge recebe eventos acionados por várias ações, como novos pedidos ou atualizações do menu.
• Ele encaminha eventos para as funções relevantes do Lambda, iniciando as ações apropriadas.
• O EventBridge suporta a repetição de eventos, permitindo a recuperação de problemas de implantação do Lambda ou falhas de função. Esse recurso permite a continuidade dos negócios armazenando eventos durante interrupções no serviço e retomando automaticamente o processamento quando o sistema se estabiliza.

Para manter o histórico de pedidos e permitir a rápida recuperação de dados, o sistema precisa de um banco de dados de alto desempenho. O Amazon DynamoDB, um serviço de banco de dados NoSQL Serverless, atende a esses requisitos armazenando e gerenciando informações e metadados de pedidos com eficiência. A função Lambda de processamento de pedidos interage com o DynamoDB para manter os detalhes do pedido. Essa abordagem permite o processamento assíncrono dos dados armazenados por outros processos de back-end. A solução de banco de dados fornece a escalabilidade e a capacidade de resposta necessárias para lidar com volumes crescentes de pedidos e, ao mesmo tempo, manter um desempenho consistente, separando a entrada de pedidos das etapas subsequentes de processamento.

Fluxo de trabalho de processamento de pedidos

As etapas a seguir descrevem o fluxo de trabalho de processamento de pedidos, conforme mostrado na figura a seguir:

• A função Lambda de processamento de pedidos valida o pedido e atualiza o banco de dados do DynamoDB com os detalhes do novo pedido.

A função publica eventos de erro no EventBridge, permitindo o processamento posterior para tratamento de erros e lógica de repetição. Esses eventos podem acionar mais funções do Lambda projetadas para gerenciar cenários de erro e processos de recuperação específicos.

Padrões de implementação do EventBridge: abordagens de barramento único ou duplo

O EventBridge oferece várias abordagens para a topologia do barramento de eventos. Os arquitetos podem optar por usar um único barramento de eventos com padrões de eventos distintos com base no status do pedido ou implementar uma estratégia de vários barramentos.

A abordagem de barramento único usa um barramento de eventos para todos os eventos com padrões de regras de roteamento baseados no status do pedido. Por exemplo, as regras corresponderiam a status específicos (por exemplo, “novo” ou “processado”) para acionar funções Lambda apropriadas. Embora seja arquitetonicamente simples, ele precisa de um gerenciamento cuidadoso do esquema de eventos para evitar possíveis erros. No entanto, uma abordagem de barramento único requer um tratamento cuidadoso para evitar o processamento recursivo, em que as mensagens acionam mensagens adicionais em um loop infinito.

Como alternativa, o método de vários barramentos, que separa a colocação e o processamento de pedidos em diferentes barramentos, evita efetivamente problemas de loops e recursão. Essa abordagem fornece uma melhor separação das transações, embora com uma configuração um pouco mais complexa.

O EventBridge pode direcionar diretamente serviços externos usando a opção de destino da API, eliminando a necessidade de funções Lambda para integrações de terceiros.

Orquestrando o processamento de pedidos

Em sistemas complexos de processamento de pedidos para QSRs, gerenciar várias funções Lambda interdependentes pode se tornar um desafio, levando potencialmente a códigos complexos e arquiteturas de difícil manutenção. Para resolver isso, o AWS Step Functions pode ser introduzido como uma camada de orquestração.

O Step Functions atua como um coordenador central da lógica de negócios necessária nos fluxos de pedidos de QSR. Esse serviço gerencia a progressão das atividades no fluxo de trabalho de processamento de pedidos, coordenando com eficiência tarefas como preparação da cozinha e logística de entrega. Definir e gerenciar fluxos de trabalho complexos permite que o Step Functions otimize a eficiência geral das operações de QSR, fornecendo uma solução estruturada e adaptável. Essa orquestração aprimora a capacidade do restaurante de lidar com o processamento dinâmico, alcançando uma integração suave e responsiva com os serviços de entrega e, ao mesmo tempo, simplificando a arquitetura subjacente.

As etapas a seguir descrevem a orquestração do processamento de pedidos, conforme mostrado na figura a seguir:

• O processamento de pedidos aciona a respectiva função Lambda, que atualiza os dados do pedido no banco de dados do DynamoDB.
• O pedido atualizado é disponibilizado para funções subsequentes do Lambda que processam mais lógica de negócios executada por outras funções do Lambda.

Em uma arquitetura EventBridge de vários barramentos, os fluxos do processo são os seguintes:

1. O primeiro barramento do EventBridge recebe o evento de pedido inicial e o encaminha para um fluxo de trabalho do Step Functions.
2. O fluxo de trabalho do Step Functions orquestra o processamento de pedidos, coordenando várias tarefas e verificações.
3. Após a conclusão, o fluxo de trabalho do Step Functions emite um evento com os resultados do processamento para o segundo barramento do EventBridge.
4. Com base na saída do fluxo de trabalho do Step Function, esse segundo barramento contém uma regra que aciona a API Aggregator como destino da API.

Fluxo de trabalho de engajamento do usuário

Quando um cliente faz um pedido, deve haver uma forma de confirmá-lo ou notificá-lo quando o pedido estiver pronto. Para isso, você pode usar os serviços do AWS End User Messaging para enviar notificações para conclusão de pedidos e novas ofertas aos clientes.

A análise dos dados do cliente e das preferências individuais permite que o Amazon Personalize seja usado para apresentar recomendações e promoções personalizadas.

O Amazon Personalize pode analisar dados históricos de pedidos para aprimorar a experiência do usuário por meio de recomendações personalizadas, como prazos de entrega ideais, itens de menu preferidos e promoções personalizadas com base em padrões de pedidos individuais.

Conclusão

Esta postagem mostrou como usar os serviços Serverless da AWS para criar uma plataforma para o processamento de pedidos sem se preocupar com o gerenciamento da infraestrutura subjacente. Os serviços Serverless incluídos foram Amazon API Gateway, AWS Lambda, Amazon EventBridge, AWS Step Functions, AWS End User Messaging e Amazon Personalize.

Esta postagem é uma breve introdução às arquiteturas orientadas por eventos focadas nas integrações de sistemas de pedidos internos com agregadores de entrega e plataformas de pedidos de terceiros. Isso pode ajudar a expandir a base de usuários e tem sido um fator-chave no crescimento de muitos QSRs. Tornar a experiência de pedido, retirada e entrega mais eficiente se traduz em crescimento de receita, redução do abandono de pedidos, bem como maior retenção recorrente de clientes e fidelidade à marca.

Para obter mais recursos de aprendizado Serverless, visite Serverless Land. Para encontrar mais padrões, acesse diretamente a Coleção de padrões Serverless.

Este conteúdo foi traduzido da postagem original do blog, que pode ser encontrada aqui.

Autores

	Mike Gomez é Technical Account Manager na Amazon Web Services (AWS).
	Salman Ahmed é Senior Technical Account Manager na Amazon Web Services (AWS).
	Sunaina Karve é Senior Technical Account Manager na Amazon Web Services (AWS).

Biografia do tradutor

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/

Biografia do Revisor

Rodrigo Peres é arquiteto de soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.