Platform engineering para ecommerce de bebidas nacional na ACT Digital

Na ACT Digital, atuo no time de Platform Engineering alocado ao Grupo Petrópolis — uma das maiores empresas de bebidas do Brasil. A superfície comercial que a maioria sente no dia a dia é o Bom Parceiro: um aplicativo de ecommerce em React Native com mais de 40.000 usuários ativos e recorrência anual acima de R$1 bilhão.

Este caso de estudo descreve o formato dessa atuação: como é o trabalho de plataforma em escala comercial, como mantemos serviços, mobile e integrações empresariais coerentes, e as práticas de engenharia que transformam infraestrutura em alavancagem para times de produto.

O papel

Entrei como Desenvolvedor Full Stack no Platform Team de ecommerce. O briefing não é ser dono de um único feature para sempre. É construir e evoluir a infraestrutura compartilhada, os serviços em cloud e as capacidades de engenharia das quais o ecossistema comercial da empresa depende — para que times de produto entreguem com confiabilidade sem reinventar as mesmas bases.

A ownership no dia a dia atravessa:

• Serviços backend e APIs de plataforma em Node.js, NestJS e TypeScript
• Soluções em cloud na AWS que precisam permanecer escaláveis e operáveis
• Pipelines de CI/CD, fluxos de deploy e padrões de entrega
• Integrações empresariais — em especial SAP — para dados comerciais e de pedidos
• Trabalho de performance em APIs e no cliente mobile do Bom Parceiro
• Code reviews, testes automatizados e documentação que mantêm o padrão consistente

O espaço do problema

Ecommerce comercial nessa escala falha de formas operacionais antes de falhar de formas espetaculares. Um caminho de pedido que espera cada hop empresarial parece quebrado mesmo com todos os serviços "no ar." Uma tela mobile lenta perde confiança com parceiros que vivem dentro do app o dia inteiro. Um sync com SAP que desvia em silêncio gera tickets de suporte que parecem bugs de produto.

O Grupo Petrópolis precisava de capacidades de plataforma que aguentassem pressão comercial real:

• APIs críticas usadas por dezenas de milhares de usuários ativos
• Sincronização confiável de dados comerciais, de clientes e pedidos com o SAP
• Experiências mobile no Bom Parceiro que permanecessem ágeis em redes imperfeitas
• Fluxos de checkout e pagamento em que segundos de latência viram vendas abandonadas
• Pipelines de entrega em que múltiplos times de engenharia pudessem confiar
• Observabilidade e padrões para que incidentes fossem diagnosticáveis, não conhecimento tribal

Essa combinação empurra o trabalho de plataforma para limites de microsserviços, integração event-driven onde sync seria desonesto, e operações sustentadas na AWS — não um monólito respondendo a cada request comercial de forma síncrona.

O que eu construí

APIs de plataforma e microsserviços

Construo e mantenho serviços backend e APIs de plataforma com Node.js, NestJS e TypeScript, com PostgreSQL como store central. Esses serviços suportam aplicações comerciais críticas: contratos claros para consumidores mobile e internos, comportamento de erro previsível e limites de serviço que permitem evoluir domínios sem acoplar cada release.

Onde o domínio justificava, aplicamos pensamento de microsserviços — ownership separada de fluxos comerciais, integrações e preocupações compartilhadas de plataforma — em vez de crescer um único serviço até toda mudança virar imposto de coordenação.

Infraestrutura cloud na AWS

Desenvolvo e opero soluções baseadas em cloud na AWS, incluindo pegada com Lambda, API Gateway, S3 e CloudWatch. O objetivo é prático: melhorar escalabilidade e resiliência sem tornar a plataforma mais difícil de operar. Containers com Docker mantêm ambientes locais e de pipeline honestos sobre o que sobe para a cloud.

CI/CD e processo de engenharia

Projeto, automatizo e melhoro pipelines de CI/CD, fluxos de deploy e processos de engenharia. O valor de plataforma se multiplica quando publicar é chato: menos passos manuais, sinais de falha mais claros e caminhos de entrega que times de produto reutilizam em vez de inventar rituais por squad.

Integrações SAP

Projeto e mantenho integrações com SAP, garantindo sincronização confiável de dados comerciais e de pedidos entre sistemas distribuídos. Usamos arquiteturas event-driven onde request/response síncrono forçaria o mobile ou as APIs a esperar hops empresariais que não controlamos. A parte difícil raramente é "chamar a API." São retries, falhas parciais, idempotência e manter a verdade comercial coerente quando os sistemas discordam por um momento.

Performance no backend e no mobile

Melhoro a performance da aplicação encontrando gargalos nos serviços backend e no cliente React Native do Bom Parceiro. Esse trabalho reduziu o tempo de resposta das APIs em 72% e o tempo de carregamento de telas em 31%. No caminho de checkout, ajustamos o fluxo de pagamento de 13 segundos para 9 segundos, melhorando a experiência de venda onde a latência é sentida de forma mais direta.

Padrões que reduzem dor em produção

Por meio de code reviews, testes automatizados, documentação e práticas compartilhadas de desenvolvimento, contribuímos para uma redução de 18% nos reportes de bugs em produção. Platform engineering também é cultura: as mesmas convenções que aceleram reviews também tornam incidentes mais raros.

Esboço de arquitetura

Em alto nível, a plataforma comercial se parece com isto:

Bom Parceiro (React Native)
        │
        ▼
   API Gateway / APIs de plataforma (NestJS)
        │
        ├──► Microsserviços comerciais ──► PostgreSQL
        │
        ├──► Caminho de pagamento / checkout
        │
        └──► Sync event-driven
                    │
                    ▼
              SAP e sistemas empresariais
                    │
                    ▼
         AWS (Lambda, S3, CloudWatch) + CI/CD

Nem todo feature precisa de todas as caixas. O ponto é ter limites honestos: requests interativos do mobile permanecem rápidos, o sync empresarial acontece onde deve, e operadores conseguem ver o que falhou quando algo desvia.

Práticas de engenharia que importaram

Alguns hábitos se pagaram repetidamente:

• Instrumentar antes de otimizar — CloudWatch e métricas de serviço tornaram latência e modos de falha visíveis antes de tickets de parceiros.
• Manter contratos mobile estáveis — o Bom Parceiro depende de APIs previsíveis; quebrar contratos em silêncio é pior do que quebrá-los em alto.
• Tratar sync com SAP como problema de confiabilidade — retries, idempotência e handoffs event-driven vencem a esperança de que o sistema empresarial responda a tempo para um spinner.
• Automatizar a entrega — CI/CD e fluxos compartilhados reduzem o imposto que cada time paga para publicar com segurança.
• Medir os caminhos que vendem — latência de pagamento e de carregamento de tela são resultados de produto, não métricas de backend de vaidade.

Resultados

Essa atuação é trabalho de plataforma com consequências comerciais: APIs mais rápidas, telas mobile mais ágeis, caminho de pagamento mais curto e menos bugs em produção — mantendo AWS, SAP e padrões de entrega coerentes para os times que constroem por cima.

Resultados concretos do trabalho acima:

• 72% de redução no tempo de resposta das APIs
• 31% de redução no tempo de carregamento de telas
• Fluxo de pagamento melhorado de 13s para 9s
• 18% menos reportes de bugs em produção
• Serviços NestJS/TypeScript compartilhados, operações na AWS e integrações SAP que times de produto reutilizam

Stack

Encerramento

A ACT Digital me colocou em um time de Platform Engineering que precisa fazer software comercial parecer confiável em escala nacional. O trabalho fica sob o Bom Parceiro e o ecossistema mais amplo do Grupo Petrópolis: APIs, cloud, integrações, entrega e a disciplina de performance que transforma investimento em plataforma em velocidade para o parceiro. Se você contrata para engenharia de plataforma ou ecommerce com restrições parecidas, esse é o tipo de ownership que eu levo.