OnDelivery: a arquitetura por trás da plataforma

Como eu estruturei o OnDelivery: monorepo, vários serviços em NestJS e Express.js, mensageria com BullMQ e RabbitMQ e entrega em contêineres.

1. Contexto & Desafio de Engenharia

Cenário Operacional:

O OnDelivery é a plataforma que eu desenvolvo para restaurantes e deliveries: pedidos, PDV, entregas, catálogo, estoque, caixa, cupons, fidelidade e uma loja online para o cliente final, além de apps para garçom, entregador, cozinha (KDS), totem e cardápio QR. Organizei o código como um monorepo com vários serviços. O backend usa NestJS e Express.js sobre PostgreSQL, com BullMQ e RabbitMQ no processamento assíncrono; os front-ends são em Next.js e React. Tudo roda em contêineres, com testes e CI no GitHub Actions.

O Gargalo / Problema Técnico:

O que mais exige atenção numa plataforma assim: • Manter claras as fronteiras entre os pacotes do monorepo, mesmo com repositório e pipeline compartilhados. • Coordenar contratos, configuração e consistência de dados entre serviços independentes. • Garantir entrega, idempotência e rastreabilidade das mensagens entre os serviços. • Manter as imagens de contêiner enxutas, seguras e reproduzíveis.

2. Decisões

A arquitetura se apoia em quatro escolhas: • Monorepo: todos os pacotes num só repositório, com workspaces. • Vários serviços: cada serviço com o próprio código e contêiner, orquestrados com Docker Compose. • Mensageria assíncrona: BullMQ e RabbitMQ entre os serviços. • Contêineres: Dockerfiles e Docker Compose para construir e subir tudo.

3. Topologia & Fluxo de Dados

OnDelivery: a arquitetura por trás da plataforma

Rendering architectural diagram...

4. Implementação & Padrões

Stack por camada: • Linguagens: TypeScript, Go e Python • Runtime: Node.js • Backend: NestJS, Express.js e WebSocket / Socket.io • Frontend: Next.js, React, Tailwind CSS e TanStack Query • Dados: PostgreSQL com TypeORM e Redis • Mensageria: BullMQ e RabbitMQ • Validação: Zod • Testes: Jest, Vitest e Playwright • Entrega: Docker, GitHub Actions e NGINX • Observabilidade: OpenTelemetry, Grafana, Prometheus, Loki e Tempo Entrega e qualidade: • O repositório tem testes com Jest, Vitest e Playwright, CI no GitHub Actions, Dockerfiles e um Docker Compose.

5. Trade-offs & Decisões Conscientes

• Monorepo: facilita mudanças atômicas entre pacotes e o tooling compartilhado, mas exige cuidado com o pipeline e com o acoplamento acidental entre pacotes. • Vários serviços: cada serviço sobe e escala sozinho, ao custo de mais operação, observabilidade distribuída e consistência eventual entre eles. • Mensageria assíncrona: desacopla os serviços no tempo e absorve picos de carga, mas a depuração fica mais difícil e os consumidores precisam ser idempotentes. • Contêineres: garantem paridade entre ambientes e deploy previsível, com o custo de manter as imagens base atualizadas.

6. Resultados

Neste estudo eu foco na arquitetura. Métricas de uso e resultados ficam para um próximo texto.