Encontrar a foto.
Concluir a compra.
Exibir fotos é só uma parte do produto. As imagens precisam ser enviadas, processadas e armazenadas. Os clientes precisam encontrá-las, comprá-las e acessar os arquivos corretos.
O processamento acontece em segundo plano enquanto a loja atende à navegação e à compra. Eventos de pagamento e estado do pedido determinam o acesso aos arquivos comprados.
Conectar a imagem,
a compra e a entrega.
Minha responsabilidade abrangeu o fluxo de mídia, as integrações de pagamento e os produtos associados a cada foto, com atuação também no frontend.
O que assumi no projeto
- Upload, filas, jobs, marca d’água e integração com processador de mídia e armazenamento.
- Pix, cartão e pagamento presencial; checkout, webhooks e reconciliação dos pedidos.
- Arquitetura de produtos associados a cada foto.
- Integração entre loja, painel administrativo e Core API.
A estrutura por trás
do produto.
O mapa mostra as principais responsabilidades e conexões. Amplie para explorar o fluxo ou escolha uma camada para entender seu papel no sistema.
Ler o diagrama em texto
A loja e a administração Next.js chamam a Core API Hono. O Core acessa PostgreSQL por Drizzle e Hyperdrive, integra pagamentos Mercado Pago e publica jobs nas Cloudflare Queues. Um Jobs Worker separado consome filas e agendamentos, chama o processador Fastify e Sharp, indexa rostos com Rekognition, envia e-mails via Resend e persiste o estado dos jobs. O processador lê e grava objetos no R2. Esta visão seletiva omite detalhes de autenticação, a entrega direta de imagens e alguns caminhos de leitura.
Dar à interface um contrato claro com o backend.
Loja e administração usam a Core API para galeria, uploads, carrinho, checkout, pagamentos e downloads. O acesso aos dados usa Drizzle e Hyperdrive no deploy. O isolamento entre empresas é aplicado no backend, não por filtros da interface.
Separar requisições de trabalho em segundo plano.
O Core enfileira o trabalho. Um Jobs Worker dedicado consome mensagens e agendamentos para derivados, reconhecimento, e-mails e limpeza. Jobs precisam de estado explícito e comportamento idempotente em retentativas.
Dar um runtime próprio ao processamento pesado.
O Jobs Worker chama o processador Node.js/Fastify/Sharp, em vez de executar o processamento pesado no Core. Prévias com marca d’água são públicas; originais e derivados limpos de reconhecimento permanecem privados. Bytes públicos são entregues diretamente, sem proxy pelo Core.
Usar eventos de pagamento para definir o acesso ao pedido.
O Core integra checkout e eventos de pagamento. Webhooks exigem validação de assinatura e reserva do evento antes do processamento. Estado do pedido e acesso precisam refletir o fluxo de pagamento, com e-mail encaminhado de forma assíncrona.
O que escolhi.
Os compromissos envolvidos.
01Tirar o processamento pesado do caminho da requisição.HTTP, fila e processamento têm responsabilidades distintas.
Escolha de arquitetura
Usar Core para HTTP, Queues para entrega dos jobs e um Jobs Worker separado para chamar o processador Fastify/Sharp. Em produção, o processador não recebe chamadas diretas da loja.
A contrapartida
O produto precisa apresentar os estados de processamento com clareza. Filas, retentativas, processamento externo e estado no banco precisam funcionar em conjunto.
02Separar prévias públicas de originais privados.Exibir a prévia sem publicar o arquivo original.
Escolha de arquitetura
Entregar prévias com marca d’água pelo R2 público e manter originais e derivados limpos de reconhecimento em armazenamento privado, com acesso controlado.
A contrapartida
Uma imagem não é só uma URL. Caminhos, tipos de derivados e regras de acesso precisam permanecer coerentes para não publicar o arquivo errado.
03Preparar eventos de pagamento para repetição.Uma notificação repetida não deve gerar efeitos duplicados.
Escolha de arquitetura
Validar assinaturas dos webhooks e reservar eventos antes de processá-los; modelar explicitamente as mudanças de estado de pedidos e pagamentos.
A contrapartida
Entrega pela rede não garante execução única. O tratamento dos eventos e os jobs seguintes precisam evitar efeitos duplicados e pedidos inconsistentes.
Da decisão
à implementação.
Fluxo de processamento
Upload, filas, jobs, marca d’água e integração com armazenamento.
Integrações de pagamento
Pix, cartão e presencial, com webhooks e reconciliação.
Produtos por foto
Arquitetura de produtos conectada às APIs, dados e interface.
Interface e fluxos do produto
Frontend e ajustes visuais, conectados às integrações de upload, produtos e compra.
A entrega conecta o upload do fotógrafo à compra e ao acesso do cliente aos arquivos, com caminhos separados para processamento e pagamentos.