Dietbox

Visão geral

Um SaaS brasileiro usado por nutricionistas para montar dietas e por seus pacientes para segui-las. Dois públicos com quase nada em comum dividem um produto, um sistema de identidade e uma plataforma — e essa plataforma vai de um monolito de dez anos a uma geração mais nova de serviços rodando ao lado dele.

O que eu fiz

O problema

A nutricionista vive na ferramenta o dia inteiro; o paciente abre para ler um plano alimentar. Mesmo produto, mesma base de identidade, expectativas opostas. E em 2020 um monolito .NET Framework carregava os dois no Windows App Service, com deploy uma vez por dia, de madrugada, porque era a única janela que parecia segura.

Em números

Arquitetura

O que faz

• Montagem de plano alimentar para a profissional, e o mesmo plano no app do paciente.
• Dois caminhos de cadastro sobre um único sistema de identidade — a profissional que assina e o paciente convidado por ela.
• Atualizações em tempo real enviadas a clientes abertos, sem recarregar.
• Assinaturas e cobrança recorrente.

Decisões de engenharia

• Políticas de identidade customizadas em vez de um login pronto

  Dois públicos dividem um produto, mas não um caminho: a profissional que assina, o paciente convidado por ela. Políticas customizadas de B2C deram a cada um seu próprio fluxo de cadastro, login e senha, com marca própria, sobre uma única base de identidade em vez de duas bases de usuários para manter sincronizadas.

• Blocos compartilhados antes de serviços compartilhados

  Os serviços mais novos partem de uma camada comum de domínio, infraestrutura e identidade em vez de cada um inventar a sua. É o que permitiu a um time pequeno adicionar um serviço sem que cada novo chegasse num estilo novo.

• Event sourcing no portal, não em tudo

  As perguntas do portal são históricas — o que mudou, quando e por quem —, então seu estado é derivado de eventos. O resto da plataforma não é, porque o resto da plataforma não faz essa pergunta, e event sourcing tem um custo de manutenção em todo serviço que o adota.

• Tempo real como serviço próprio

  Conexões de longa duração escalam num eixo diferente do tráfego de requisições, e atrás de um adaptador Redis qualquer instância consegue enviar a um cliente conectado em outra. Mantê-lo dentro do monolito teria amarrado os dois ao mesmo deploy — e o monolito subia uma vez por madrugada.

O que mudou sob minha direção

• De um deploy noturno a vários por dia

  Trouxe Scrum e trunk-based development. Deploy em horário comercial deixou de ser evento.

• Uma migração de pagamentos que ninguém notou

  Planejei e conduzi a migração de milhares de assinantes ativos de Iugu para Pagar.me. A receita não parou em momento nenhum — o tipo de mudança cuja medida de sucesso é não ter acontecido nada.

• Custo de nuvem como problema de engenharia

  Fiz uma revisão de custos no ambiente Azure — sem congelar entregas para bancar a economia.

• Reportar engenharia na língua da diretoria

  Passei a levar métricas DORA e um roadmap à diretoria, para que o investimento em tecnologia fosse defendido com evidências, não com convicção.