Dynamox

cargo
período
domínio
Full Stack Developer (nível pleno)
2025-Present
Inspeção industrial & monitoramento de condição
Empresa de monitoramento e inspeção industrial onde cresci de júnior a desenvolvedora full-stack plena, tornando-me a referência do time em sincronização de dados entre serviços.

A Dynamox constrói uma plataforma de monitoramento e inspeção industrial (manutenção preditiva para ativos industriais). Entrei em fevereiro de 2025 e trabalho no squad dono do domínio de inspeção: rotas de inspeção, checklists, times, conformidade ("adherence") e relatórios, construindo tanto o frontend web quanto os serviços de backend por trás dele.

Manutenção preditiva industrial e inspeção de ativos: equipes de campo seguem rotas de inspeção, preenchem checklists sobre equipamentos, e a plataforma rastreia cobertura e conformidade para que as plantas possam agir antes que falhas aconteçam. O trabalho abrange backends pesados em dados (hierarquias grandes de ativos, sincronização orientada a eventos entre serviços) e UIs web voltadas ao operador.

responsabilidades
  • Entrega full-stack de funcionalidades do domínio de inspeção (frontend em React; backends em NestJS).
  • Sincronização de dados entre serviços via uma arquitetura orientada a eventos (Kafka), o domínio no qual me tornei a referência do time.
  • Confiabilidade em produção: resposta a incidentes, debugging de deadlocks/problemas de conexão, correções seguras de dados em produção.
  • Trabalho de plataforma: remediação de segurança/CVEs, observabilidade, infraestrutura de CI/CD e testes, e infrastructure-as-code para o time.
conquistas
  • +Tornei-me a referência do time em sincronização entre serviços através de uma propagação atômica de edição em sete tabelas entre dois serviços, culminando em uma decisão de arquitetura que conduzi de forma autônoma.
  • +Tornei uma suite de testes não confiável em confiável novamente, desbloqueando o CI do time, e, em review, refutei empiricamente três das quatro mudanças de produção propostas.
  • +Fundei um novo serviço de analytics/relatórios, incluindo a decisão de arquitetura OLTP-vs-OLAP por trás dele, revisada e aprovada por sete stakeholders entre engenharia e o time de plataforma, com uma revisão de risco de segurança/privacidade incorporada à própria decisão e um risco de latência que identifiquei e corrigi entre duas versões do ADR.
  • +Fui responsável por confiabilidade em produção e integridade de dados, incluindo correções de dados em larga escala seguras e reversíveis, e resposta a incidentes com post-mortems.
  • +Transformei um incidente de produção que bloqueava clientes em uma decisão de arquitetura documentada através de um post-mortem, um ADR e um consumer reconstruído, depois identifiquei a causa raiz de um deadlock de produção posterior como uma incompatibilidade de particionamento de mensageria e fechei uma lacuna de falha silenciosa com retry e uma dead-letter queue.
  • +Entreguei uma funcionalidade complexa de ponta a ponta, sozinha, entre banco de dados, backend e frontend.
  • +Elevei o patamar de engenharia do time em observabilidade, segurança e documentação, muitas vezes por iniciativa própria.
  • +Prototipei IA aplicada com um design orientado à segurança, um agente human-in-the-loop para criação de rotas em massa: o modelo classifica candidatos e nunca emite identificadores, e toda escrita passa por confirmação humana explícita. Estágio de protótipo, chegando ao modo de escrita com testes, nunca lançado em produção. (Deliberadamente não é um estudo de caso; ver a nota de curadoria ao final deste arquivo.)
  • +Eliminei um schema de API de 5.000 linhas mantido manualmente ao gerar OpenAPI a partir dos próprios decorators do código, validado em um endpoint até o resultado gerado bater com o manual, depois expandido para ~10 domínios rumo a ~21 controllers, junto com a adição do primeiro pipeline de teste de CI do serviço. (Deliberadamente não é um estudo de caso; ver a nota de curadoria ao final deste arquivo.)
  • +Tornei o hardening de containers e dependências uma prática trimestral permanente ao longo de quatro trimestres: 135 CVEs sinalizados e todos os 7 críticos remediados na primeira passagem, depois uma auditoria levada de 69 achados para 16, CVEs de SO sem correção de 160 para 0, e a imagem final de 1,64 GB para 463 MB.
  • +Identifiquei uma query do warehouse em 69% de um teto rígido de bytes antes que começasse a falhar, depois auditei minha própria migração, encontrei 79% das linhas de produção nunca preenchidas retroativamente e 9.299 alertas silenciosamente perdidos do produto, e reparei 70.502 linhas de forma idempotente.
  • +Mudei o escopo de um épico definido pelo produto ao mover onde um novo estado é tratado. Um status de "ativo hibernado" em toda a plataforma foi especificado como uma regra de exclusão para oito caminhos de leitura; aplicá-lo uma única vez no limite de escrita tornou a maior parte desse escopo desnecessária, e o design refinado substituiu o item do roadmap como a fonte da verdade do épico. Contribuição de design; desenvolvimento programado para começar em 2026-08-31, então ainda não há número entregue.
  • +Promovida de júnior a pleno em ~11 meses, respaldada por evidências em todas as seis áreas de competência.
Dados derivados eventualmente consistentes deveriam ter exatamente um caminho de computação. Múltiplos escritores derivando o mesmo valor é o defeito; consolidar a derivação é a correção.
Agentes de IA paralelos precisam do mesmo design de segurança que qualquer outro worker concorrente. Isole o trabalho deles por ownership de arquivos disjuntos, ou eles vão corromper as mudanças uns dos outros exatamente como qualquer outra race condition.
Empurre a travessia de hierarquia para o banco de dados. Uma query recursiva que retorna resultados com seus ancestrais vence uma cascata de requisições por nível que o cliente teria que orquestrar.