Diagrama de arquitetura de e-commerce: catálogo, carrinho, checkout e pedidos

Às 9h começa a liquidação. A CDN mantém as páginas de produto no ar, mas o checkout falha: dois clientes compram a última unidade da mesma jaqueta, uma nova tentativa após um timeout deixa duas retenções de pagamento em um cartão, e o depósito fica sabendo de um pedido com uma hora de atraso porque um evento se perdeu.

Nenhum desses é um problema de capacidade. São problemas de fronteira: quem é dono de quais dados e quais etapas precisam terminar enquanto o cliente espera.

Este post percorre uma arquitetura de e-commerce realista para uma loja de porte médio: componentes e propriedade dos dados, o caminho do checkout passo a passo, o pipeline de pedidos depois dele, o tráfego de pico e um diagrama da plataforma.

Comece pelo que os clientes fazem

Cinco jornadas cobrem a maior parte do que uma loja faz, com exigências muito diferentes:

Navegar e buscar carregam a maioria das requisições e toleram dados desatualizados; o checkout carrega poucas e não tolera nenhum. Grande parte da arquitetura decorre dessa divisão.

Os componentes e os dados que cada um possui

Na borda, uma CDN faz cache de páginas e imagens, e um gateway de API (ou um backend for frontend por tipo de cliente) autentica, limita a taxa e roteia o resto. Cada serviço por trás é dono dos seus dados:

Os outros serviços usam a API ou os eventos do dono, nunca suas tabelas. Estoque e pedidos precisam de transações; carrinhos e o índice de busca podem atrasar, ou até perder uma escrita, sem dano real.

O caminho do checkout, passo a passo

O checkout é o único fluxo em que o cliente espera vários serviços ao mesmo tempo:

1. Recalcule o preço do carrinho. O Checkout lê o carrinho, busca os preços atuais no catálogo e calcula imposto, frete e descontos no servidor. Nunca confie no total vindo do navegador.

2. Reserve estoque com expiração, aqui de 15 minutos:

   -- One transaction: take the stock, then record the hold
   UPDATE stock SET reserved = reserved + 2
    WHERE sku = 'JKT-042-M' AND on_hand - reserved >= 2;  -- 0 rows: out of stock, stop
   INSERT INTO reservations (checkout_id, sku, qty, expires_at)
   VALUES ('chk_41a', 'JKT-042-M', 2, now() + interval '15 minutes');
   

   Quando dois clientes disputam a última jaqueta, o nível de isolamento padrão do PostgreSQL, Read Committed, faz o segundo update esperar e reavaliar a cláusula WHERE contra a linha nova, então um deles recebe zero linhas. Um sweeper devolve ao estoque as retenções expiradas. Com uma página de pagamento hospedada, alinhe os relógios: as sessões do Stripe Checkout duram 24 horas, a menos que você defina uma expiração menor (mínimo de 30 minutos) ou as expire por conta própria; checkout.session.expired avisa quando liberar os itens.

3. Crie o pagamento com uma chave de idempotência. O Checkout pede ao PSP um pagamento do total calculado no servidor, com captura manual e uma chave de idempotência guardada antes da chamada. Após um timeout, tente de novo com a mesma chave: o Stripe devolve a resposta salva em vez de criar um segundo pagamento. As chaves têm até 255 caracteres e podem ser removidas após 24 horas.

4. Autorize. Estenda primeiro a retenção de estoque, para que ela não expire no meio do pagamento. O cliente digita os dados do cartão nos campos do PSP, então os números do cartão nunca chegam aos seus servidores, e o emissor pode pedir 3-D Secure. Em caso de sucesso, o valor fica retido: um pagamento do Stripe com captura manual passa para requires_capture e emite payment_intent.amount_capturable_updated. Confie nesse webhook, não no redirecionamento do navegador; veja o diagrama de integração de gateway de pagamento.

5. Crie o pedido. Orders cria o pedido como placed e grava OrderPlaced em uma tabela outbox na mesma transação. Depois, o Checkout manda o Inventory transformar a reserva em alocação.

6. Capture no envio. Quando o Fulfillment envia, Orders captura. No momento em que este texto foi escrito (novembro de 2026), a documentação do Stripe diz que autorizações de cartão online costumam durar 7 dias, ou 5 dias (exatamente 4 dias e 18 horas) para transações Visa iniciadas pelo lojista; depois disso o valor é liberado e o pagamento é cancelado. A maioria dos pagamentos com cartão permite uma captura, e uma captura parcial libera o restante.

Se uma etapa falhar antes de o pedido existir, desfaça as anteriores na ordem inversa: cancele a autorização, libere a retenção. Isso é uma saga com o checkout como orquestrador.

Onde dinheiro, estoque e estado do pedido mudam

Os casos difíceis ficam entre as linhas. Se uma autorização chegar depois de a retenção expirar, reserve de novo se ainda houver estoque; caso contrário, cancele a autorização e avise o cliente. Se um pedido sem estoque (backorder) passar da janela de 7 dias, capture o valor total no primeiro envio, use uma autorização estendida onde seu PSP oferecer (até 30 dias em algumas bandeiras, segundo o Stripe) ou cobre adiantado e reembolse o que não puder enviar. Alguns meios de pagamento, como ACH e iDEAL, não conseguem capturar separadamente de jeito nenhum.

Depois que o pedido é criado

Tudo depois de placed roda de forma assíncrona. Um relay publica OrderPlaced da outbox no tópico order-events, então nenhum evento se perde entre o commit e o broker (veja o padrão transactional outbox). O Fulfillment separa, embala e envia, e então publica OrderShipped, o que dispara a captura. Notifications envia os e-mails; Analytics carrega cada evento no data warehouse.

A entrega é pelo menos uma vez, então os consumidores deduplicam pelo ID do evento. Usar o ID do pedido como chave do tópico mantém os eventos de cada pedido em ordem.

O diagrama de arquitetura de microsserviços cobra o cartão depois de OrderPlaced. Isso serve para pagamentos sem interação do cliente; o 3-D Secure exige o cliente presente, então este desenho autoriza dentro do checkout.

Sobrevivendo ao tráfego de pico

Suponha uma hora de liquidação com 7.200 pedidos, taxa de conversão de 2% e 10 visualizações de página por sessão: 360.000 sessões e 3,6 milhões de visualizações de página, ou cerca de 1.000 visualizações por segundo para 2 pedidos por segundo. Cada metade precisa da sua própria proteção:

• Faça cache do catálogo na borda. Com Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60, a CDN serve uma página de produto por cinco minutos e depois por até mais um minuto enquanto a busca de novo em segundo plano, como define a RFC 5861. Com 90% de taxa de acerto, a origem vê 100 visualizações por segundo em vez de 1.000. Faça purge nas mudanças de preço; o checkout confere de novo de qualquer forma.
• Coloque uma fila na frente do checkout. Uma sala de espera virtual admite clientes em um ritmo que o Inventory e o PSP aguentem, como no design de um sistema de venda de ingressos.
• Proteja os SKUs quentes. Reservas de um SKU atualizam uma linha, uma de cada vez. Com 2 ms de tempo de bloqueio por transação, essa linha chega a um teto perto de 500 reservas por segundo. Mantenha a transação curta e sem chamadas ao PSP, divida o estoque de um item de promoção relâmpago em várias linhas e limite a quantidade por pedido.
• Conheça os limites de taxa do seu PSP antes da liquidação.

Comece menor do que isto

Muitas lojas não deveriam construir tudo isso. Uma plataforma hospedada como Shopify ou BigCommerce roda catálogo, carrinho e checkout para você; seu diagrama então mostra os apps e webhooks ao redor.

Uma construção sob medida muitas vezes começa melhor como um monólito modular: as mesmas fronteiras como módulos em um único artefato implantável. Em 2019, os engenheiros da Shopify descreveram a reorganização de uma das maiores bases de código Ruby on Rails em torno de pedidos, envio, estoque e cobrança, em vez de dividi-la em microsserviços. Extraia um serviço quando um módulo precisar de escala ou de releases próprios; o diagrama continua valendo.

O diagrama da plataforma de e-commerce

Como ler:

• As requisições entram no canto superior esquerdo: cliente, CDN e depois o gateway, que roteia cada jornada para um serviço.
• Azul é o caminho de navegação. A aresta tracejada é o índice de busca alcançando as mudanças de produto.
• Âmbar é o caminho do checkout, onde o cliente espera: ler o carrinho, reservar estoque, autorizar e criar o pedido.
• O provedor de pagamento recebe duas chamadas: autorizar durante o checkout e capturar em OrderShipped (turquesa tracejado).
• Arestas violeta tracejadas são eventos, da outbox passando por order-events até Fulfillment, Notifications e Analytics.
• Cada serviço nomeia seu armazenamento, e o bloco Markdown lista os números.

Desenhando diagramas de arquitetura de e-commerce com clareza

• Rotule as arestas do gateway com rotas como GET /products, para que os leitores associem páginas a serviços.
• Nomeie o armazenamento em cada serviço. Um banco de dados compartilhado não pode passar despercebido.
• Linha contínua para esperar, tracejada para depois. As chamadas que o cliente espera devem parecer diferentes dos eventos.
• Escreva os tempos nas arestas. A duração da retenção e o gatilho da captura são o que mais precisa de revisão.
• Desenhe autorização e captura como duas arestas. Uma seta só para o PSP esconde o tempo mais importante.
• Deixe de fora pods, regiões, fornecedores de imposto e antifraude, e o back office.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Pessoa do pacote C4 Model, depois uma CDN e um Gateway de API do pacote Nuvem, abaixo dele.
3. Adicione cinco nós Contêiner do pacote C4 Model em uma coluna: Catalog, Search, Cart, Checkout e Orders, cada um com seu armazenamento na descrição.
4. Adicione um Contêiner para o Inventory, um Sistema externo para o provedor de pagamento e um Tópico do pacote Dados para order-events. À direita deles, adicione nós Contêiner para Fulfillment e Notifications e um Armazém de dados do pacote Dados.
5. Conecte o gateway aos cinco serviços com rótulos de rota. Faça as chamadas do checkout contínuas, e as mudanças de produto, a captura e os eventos tracejados.
6. Adicione um bloco Markdown do pacote Básico com os números, e notas de Texto para a legenda e as regras principais.

Se seus serviços rodam a partir de um arquivo Compose, a ferramenta Docker Compose para diagrama esboça as caixas; o modelo de arquitetura de microsserviços é outro ponto de partida. O exemplo usa 15 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Quais são os principais componentes de uma arquitetura de e-commerce? Uma CDN, um gateway de API, serviços de catálogo, busca, carrinho, checkout, estoque e pedidos, um provedor de pagamento, e Fulfillment, Notifications e Analytics. As plataformas hospedadas reúnem a maioria deles.

Uma loja online deve usar microsserviços? Não por padrão. Um monólito modular com as mesmas fronteiras é mais simples de operar, e a Shopify escolheu um para o seu núcleo. Extraia um serviço quando um módulo precisar de escala ou de releases independentes.

Como evitar vender estoque a mais? Reserve estoque com um update atômico e condicional por SKU, dê uma expiração a cada reserva e só aloque quando o pedido for criado. Nunca decida a disponibilidade a partir de uma página em cache.

Quando uma loja online deve capturar o pagamento? Para bens físicos, normalmente no envio, para cobrar apenas o que é enviado. Autorizações de cartão online costumam durar 7 dias. No Stripe, o Klarna permite 28 dias e o PayPal 10, que o Stripe tenta estender para 20.

Como os sites de e-commerce lidam com picos de tráfego? Servem o catálogo pela CDN, colocam os clientes em fila na frente do checkout e protegem os SKUs quentes e o provedor de pagamento. Planeje a capacidade do checkout separadamente das visualizações de página.

Comece grátis — um assento, sem cartão de crédito.