Sou Jonathan Troncoso. Há mais de dez anos desenho e conduzo a arquitetura de plataformas críticas no setor financeiro — núcleo bancário, pagamentos, crédito e seguros. Trabalho na fronteira entre a decisão de negócio e a topologia técnica que a sustenta: decomposição de domínio, modernização de legado, plataforma em nuvem e, agora, engenharia orientada a agentes.
Boa parte do custo de um sistema financeiro não vem da tecnologia escolhida, mas da fronteira mal traçada entre domínios. Um limite errado se paga por anos em acoplamento, transação distribuída e mudança que ninguém consegue estimar. Meu trabalho começa antes do código: entender o negócio com profundidade suficiente para saber onde o corte dói menos.
A partir daí, tudo é decisão registrada e consequência assumida — contexto, decisão, trade-off, o que se ganha e o que se perde. Uso DDD para achar as costuras, C4 e BIAN para comunicar em linguagem que negócio e regulador entendem, e contratos explícitos para que a fronteira sobreviva ao time que a desenhou. Depois, garanto que o padrão não fique no documento: ele vira código gerado, teste e verificação automática.
Concebi e construí uma plataforma de engenharia orientada a agentes que cobre o ciclo inteiro: um agente arquiteto lê o escopo de negócio em linguagem natural e devolve um context map DDD com bounded contexts, agregados e integrações; esse mapa vira spec rígida e contract-first; agentes geradores materializam o microsserviço completo — Clean Architecture, vertical slice, camadas de domínio, aplicação, dados e borda, ACL sobre o legado, mensageria com outbox, retry e DLQ; e uma camada de governança valida conformidade arquitetural, contratos e containerização antes de qualquer merge. O que antes dependia da disciplina individual de cada squad virou propriedade executável da plataforma.
Portfólio com dezenas de serviços, times distribuídos e um padrão arquitetural que existia como documento, não como restrição. Cada novo serviço reabria as mesmas discussões e cada squad interpretava o padrão de um jeito. O custo não estava em escrever código: estava em revisar, corrigir e reconciliar divergência estrutural depois que já era tarde.
Codificar o padrão como agentes especializados e determinísticos em vez de treinamento e revisão manual. Decomposição de domínio, síntese de spec, geração de serviço e verificação de conformidade viraram etapas executáveis, versionadas e parametrizáveis por stack — .NET, Java/Spring e Node — com o mesmo modelo arquitetural em todas.
O tempo entre escopo aprovado e serviço rodando com testes, container e pipeline caiu de semanas para horas, e a revisão de arquitetura deixou de ser arqueologia para virar leitura de decisão. Em troca, a plataforma passa a ser um ativo com dono: os agentes precisam evoluir junto com o padrão, e desvio deliberado exige ADR explícito — o que é, na prática, o comportamento desejado.
A objeção mais comum a uma plataforma de engenharia não é técnica, é organizacional: ninguém quer trocar a ferramenta onde o processo de tecnologia já vive. Por isso o Arsenale Agentico tem dois modos de adoção, e o segundo é o que a maioria das empresas procura — os agentes não pedem que o time mude de lugar, eles entram no lugar onde o time já está. O Confluence passa a ser a fonte de escopo de negócio, produto e base de conhecimento; o Jira, o processo real de Scrum de onde o trabalho nasce e para onde ele volta; e o GitHub, a fonte de verdade do código e do padrão que já está de pé. Os agentes leem desses três, trabalham, e devolvem o resultado para dentro deles.
O ambiente próprio do Arsenale, com o Agent Room como superfície de operação. Faz sentido quando não existe um processo consolidado a preservar, quando o piloto precisa correr fora do fluxo oficial, ou quando a empresa quer avaliar a plataforma antes de acoplá-la a qualquer coisa.
Os agentes entram como parte do processo que já existe. Nada de portal novo, nada de migrar conteúdo, nada de pedir ao time que aprenda outra ferramenta. O épico continua sendo aberto no Jira, a página de escopo continua no Confluence, o merge continua no GitHub — o que muda é que o caminho entre eles deixa de ser trabalho manual.
O ganho não é o agente escrever código — isso qualquer ferramenta promete. O ganho é que a decisão de arquitetura nasce ligada ao épico que a motivou, o contrato nasce revisável antes de existir implementação, o serviço nasce dentro do padrão da casa, e a verificação de conformidade acontece antes do pull request e não na revisão de alguém cansado numa sexta-feira. O rastro entre a intenção de negócio escrita no Confluence e o commit que entrou no GitHub deixa de ser reconstruído por arqueologia e passa a existir por construção.
Entre o Figma e o app existe um gargalo caro e repetitivo: cada tela é reimplementada à mão olhando o design, ninguém sabe sem abrir o Figma o que já foi feito e o que falta, trocar de identidade obriga a retrabalhar tudo, e a navegação vive na cabeça de alguém em vez de num artefato consultável. Transformei esse gargalo numa linha de produção — arquitetura de super-app, design system e implementação de telas conduzidos por agentes, com fidelidade ao design e validação em dispositivo.
React Native com Module Federation: um host carrega mini-apps federados em runtime, cada um desenvolvido, versionado e implantado por um time independente. O Design System entra por módulo, não como singleton federado — host e mini-apps podem rodar versões ou marcas diferentes ao mesmo tempo, que é o que torna rebrand gradual e whitelabel possíveis. O runtime de federation já vem endurecido: compartilhamento de dependências, resolução de chunks por plataforma e bytecode em release.
Um gerador que produz ou retematiza o Design System do app a partir de um site, de tokens, de um arquivo de design ou do próprio Figma: paleta, tipografia, escala de espaçamento e tokens aplicados em todos os componentes, sempre em tema claro e escuro. Tem preview mobile dos componentes antes de publicar, refino por conversa com versionamento da saída, download das fontes reais e um script que leva fontes e assets prontos para os projetos mobile.
O ponto de virada, e o que dispensa qualquer captura de tela. O time de design seleciona os nodes no Figma e cola a lista de links; o Flow Mapper lê a estrutura real pela API e classifica cada node em tela, seta de navegação ou anotação do designer — anotação não é tela e é ignorada. Depois monta a sequência da jornada com as ligações derivadas das setas, associa cada tela ao template certo do Design System e salva tudo em arquivo consultável. Um log de duplicados marca o que já foi processado, então nada é reimplementado.
Com a jornada mapeada, um agente cuida de cada tela pendente: lê o design real daquele node — textos, itens e valores, sem chutar conteúdo —, compõe com os componentes reais do Design System em vez de desenhar do zero, baixa e versiona os assets, escreve a tela no padrão do projeto, registra a navegação e valida o build. Telas independentes são construídas em paralelo, e o plano mostra o que já está feito contra o que falta, com a página se atualizando sozinha de pendente para em andamento e para feito.
Lê a estrutura do Figma, não uma imagem, e por isso distingue tela de seta e de anotação. Constrói sobre o Design System em vez de reproduzir pixel a pixel, então as telas nascem consistentes, temáveis e acessíveis. É rastreável de verdade: manifesto do que existe, plano de pendências e log de duplicados. Marca vira parâmetro, não projeto. E validação em dispositivo faz parte da entrega — build verde e tela renderizada, não uma promessa de que deve funcionar.
Numa implementação de referência de um mini-app de consórcio dentro de um super-app financeiro: cerca de dezesseis telas construídas a partir do Figma em duas jornadas, cada uma fiel ao design — barra superior, cartões de oferta, badges de status, filtros, seção de valores, histórico de pagamentos, detalhe da parcela. A classificação automática separou telas reais de setas e de anotações numa seleção de quinze a dezessete nodes. Até dez telas de uma jornada foram implementadas concorrentemente. A navegação ficou amarrada de ponta a ponta, o bundle compilou sem erros e o render foi verificado em iOS e Android. E o app inteiro foi repontado para outra versão do Design System, com re-tematização completa, sem alterar o código das telas.
O ganho não é escrever tela mais rápido — é transformar design-to-code em processo industrial: rastreável, fiel, reaproveitável e verificável. Em troca, o Design System deixa de ser documentação e passa a ser dependência de produção: se ele não tiver o template, a fábrica para. O board do Figma precisa ser disciplinado, porque a classificação lê estrutura e não adivinha intenção. E a fábrica é um ativo com dono — precisa evoluir junto com o Design System e com o padrão do projeto, sob pena de gerar tela que já nasce fora de padrão.
Avalio o Figma, o Design System e a arquitetura mobile, e entrego o plano para industrializar o design-to-code.
Monto a arquitetura de host com mini-apps federados e o Design System temável por módulo.
Do Figma ao app: mapeio a jornada e implemento as telas sobre o Design System, com navegação e validação em dispositivo.
Retematizo o app inteiro com um Design System novo, sem retrabalhar as telas.
Instalo o processo e as ferramentas no seu time, com transferência de propriedade.
Clientes e marcas omitidos por acordo — setor, país e período preservados. O que interessa aqui não é o logotipo: é a restrição que existia antes, a decisão estrutural que a resolveu e o que essa decisão custou em troca.
O Agent Room não é um produto separado: é a superfície do Arsenale Agentico que mostra como os agentes estão se comportando enquanto executam. Cada agente especializado — decomposição de domínio, síntese de spec, geração de serviço, verificação de conformidade — aparece com o que leu, o que decidiu, em que etapa está e onde travou. O ciclo descrito na seção anterior deixa de ser inferido pelo resultado e passa a ser observado em curso.
Pipeline de agentes é caixa-preta por natureza: entra um escopo, sai um serviço, e o meio é opaco. Quando a geração diverge do padrão arquitetural, não dá para saber em qual etapa a interpretação escorregou — e, sem isso, o diagnóstico vira tentativa e erro sobre o resultado final.
Expor o comportamento de cada agente em execução como dado de primeira classe: entrada consumida, decisão tomada, etapa corrente e ponto de parada, emitidos por etapa e não apenas no fim do ciclo.
Uma execução passa a ser comparável com a outra e o desvio fica localizado na etapa exata em que o padrão deixou de ser respeitado — que é a informação necessária para corrigir o agente, não o código gerado. Em troca, a superfície vira parte do contrato da plataforma: agente novo que não emite comportamento nasce cego.
Desenho da arquitetura de uma banca conversacional com IA sobre dez casos de uso — boas-vindas contextual, análise de gastos, venda proativa de crédito, retenção, cobrança com refinanciamento, prevenção de mora, alerta de fraude, desbloqueio biométrico, investimento de saldo ocioso e disputa de cobrança não reconhecida — priorizados por complexidade de raciocínio exigida do agente, cruzada com regime de latência e perfil de risco. O ponto de partida não foi adotar um modelo de linguagem: foi reconhecer que o banco passou a operar duas malhas de comunicação com perfis de tráfego incompatíveis. A malha transacional síncrona determinística vive abaixo de duzentos milissegundos, com payload em kilobytes e fluxo linear, servindo doze canais humanos através de gateway, BFF por canal e camada anticorrupção sobre os cores legados. A malha agêntica tem latência de dois a cento e vinte segundos, payload em megabytes correspondente ao context window inteiro, fluxo não-determinístico com chamadas de ferramenta em laço, e a obrigação de propagar a identidade do cliente original através de múltiplos saltos entre agentes. Toda a arquitetura de nove camadas — dos canais agênticos à borda paralela, ao runtime de agentes, ao roteador e planejador, ao gate de política determinístico, aos doze servidores MCP tipados, à integração e aos cores — existe para sustentar essa separação sem duplicar lógica de leitura.
Promover agentes para dentro do gateway interno da malha transacional degradaria o SLA do canal humano: um agente em laço consome as mesmas APIs de core que atendem doze canais em produção. Ao mesmo tempo, construir uma exposição paralela completa duplicaria lógica de leitura de forma inaceitável. As duas malhas se cruzam num único ponto — o gateway de ferramentas, que precisa invocar as mesmas APIs de core — e é essa fronteira, não o modelo de linguagem, que decide se a coisa toda funciona.
Quatro decisões acopladas, cada uma precondição ou consequência das outras. A exposição do core é híbrida: leitura reusa as APIs anticorrupção existentes sob um identificador de consumidor agêntico próprio, com disjuntor dedicado para que um agente em laço jamais alcance o canal humano; escrita passa por um servidor de ação dedicado que injeta chave de idempotência derivada do identificador de correlação, propaga a correlação e carrega o identificador de consentimento. O roteamento de modelos segue mistura de modelos por papel — modelo forte no roteador de intenção, no planejador e nos subagentes de negociação, cobrança, investimento e disputa; modelo leve nos subagentes de resposta dialógica, síntese e classificação sobre vocabulário fechado — com retorno automático ao modelo forte quando a confiança cai ou a saída estruturada falha na validação de esquema. Escritas distribuídas usam saga orquestrada com estado durável e compensações como ferramentas tipadas explícitas, escolhida sobre coreografia porque auditoria regulatória exige um rastro por saga e não uma reconstrução por agregação de eventos. E a aprovação humana obedece a uma matriz de quatro dimensões — valor financeiro, tipo de ação, perfil do cliente e risco contextual — com o risco contextual funcionando como sobreposição não negociável.
O raio de dano das escritas agênticas fica isolado e cada caminho ganha SLA próprio, ao custo de manter temporariamente dois caminhos de escrita e de sincronizar governança de esquema entre eles — mitigado com teste de contrato automatizado e registro de esquema versionado. O roteamento por papel corta a conta de inferência de forma material sem perder qualidade nos papéis críticos, mas transforma política de modelo em código versionado e exige suíte de avaliação por papel rodando continuamente. A saga orquestrada entrega um rastro auditável por operação, consumível por conformidade sem agregação, e em troca torna o orquestrador ponto crítico, com recuperação por releitura de estado e engenharia de caos periódica. E a matriz de aprovação humana preserva a experiência nos casos de baixo impacto e a segurança nos de alto, ao preço de governança contínua: a matriz é revisada trimestralmente por arquitetura, risco e conformidade, e precisa permanecer alinhada à matriz de aprovação dos canais humanos, sob pena de o mesmo cliente receber tratamento diferente conforme a porta de entrada. Três princípios ficaram inegociáveis: o modelo nunca decide sozinho, decide por ferramenta tipada e governada; o modelo nunca calcula valor financeiro, busca o número no serviço determinístico; e a identidade do cliente atravessa todos os saltos, com o canal de atendimento carregando simultaneamente a identidade do operador, a do cliente e o consentimento gravado.
Condução de avaliação de arquitetura e definição de solução corporativa para as linhas de negócio de um banco de varejo chileno, com a responsabilidade de desenhar a arquitetura conceitual, liderar o time técnico de arquitetura e sustentar uma estratégia tecnológica de longo prazo ancorada no objetivo comercial — não no catálogo de ferramentas. O escopo técnico incluía definir e defender a solução que atendesse simultaneamente desempenho, escalabilidade, flexibilidade, operação e capacidade, num parque que mistura Java e SpringBoot com Kotlin, Python em Django e Flask e serviços em NodeJS, rodando sobre WebSphere 9, Liberty e Tomcat, com JPA e Hibernate na persistência, IBM MQ na integração assíncrona, Maven e Ant no build, JSF com PrimeFaces e IceFaces nas telas herdadas, Netflix Hystrix e Spring Cloud na resiliência distribuída, aplicações baseadas em OSGi e a persistência repartida entre Oracle, MongoDB e PostgreSQL.
Banco de varejo em praça regulada, com parque heterogêneo acumulado por décadas: servidor de aplicação corporativo convivendo com serviços novos, três bancos de dados com modelos distintos e times de negócio pedindo velocidade que a topologia herdada não entrega. Decisão de arquitetura ali não é escolha de stack — é negociação entre o que o negócio precisa e o que a operação suporta sem janela.
Tratar a arquitetura como função corporativa e não como revisão pontual de projeto: avaliação formal de arquitetura antes do compromisso, desenho conceitual como artefato próprio, liderança direta do time técnico de arquitetura e estratégia tecnológica de longo prazo escrita a partir do objetivo comercial de cada linha de negócio.
O escopo técnico passa a ser definido e defendido antes da estimativa, o que desloca a discussão de prazo para o momento em que ela ainda é barata. O custo é que a função de arquitetura vira gargalo se não tiver time e mandato — por isso liderar o time técnico fazia parte do desenho, não era acessório.
Desenho do padrão arquitetural de referência — MASA, BIAN-like, cem por cento API síncrono — e do guia de desenvolvimento que a equipe usa como referência diária, para modernizar a plataforma de consórcio sobre um núcleo legado que continua rodando. O catálogo de partida tem 94 domínios e 389 endpoints documentados em três APIs sobre ASP.NET Core com JWT Bearer: o módulo de autoatendimento do consorciado, com 22 domínios e 109 endpoints, que sustenta o Mini App; o módulo de atendimento, núcleo de back-office e domínio mestre da cota, com 67 domínios e 236 endpoints detalhados dentro de uma plataforma que declara mais de mil endpoints; e o módulo de venda, front de originação da jornada de simulação à proposta assinada, com 5 domínios e 44 endpoints. A matriz de serviços de domínio cobre 1.083 operações. O ciclo de vida da cota está inteiro ali: assembleia, contemplação, lance, cobrança, negociação de dívida em dezesseis subdomínios especializados, amortização por FGTS, alienação fiduciária, seguro e sinistro, transferência, devolução e encerramento. O mapeamento das telas do Mini App contra o catálogo fechou em 12 telas cobertas pela API do consorciado, 6 atendidas apenas pelo back-office e 7 sem endpoint correspondente — lacuna declarada em vez de descoberta em produção.
Um núcleo legado de consórcio com mais de mil endpoints, times distribuídos e um padrão que existia como documento. Sem restrição executável, cada squad interpretava fronteira de domínio do seu jeito, lia banco alheio quando era mais rápido e vazava código de erro do legado para dentro do contrato público — dívida que só aparece quando já é estrutural.
Um domínio, um microsserviço, um banco — database-per-service, sem leitura de base alheia nem do legado, cujo acesso passa obrigatoriamente por uma camada anticorrupção que traduz contrato, estado e erro e nada mais. Contract-first sempre: nenhuma linha antes do OpenAPI revisado, rota canônica em linguagem de negócio, escopos OIDC por domínio, escrita com Idempotency-Key e envelope de erro canônico em application/problem+json preservando o código de origem. Nenhuma fila, evento, barramento ou CDC: colaboração entre domínios é chamada síncrona orquestrada com compensação, o que empurra a disponibilidade para a disciplina das chamadas de saída — timeout de 3 segundos em consulta e 10 em comando com budget decrescente na cadeia, retry só em idempotente com duas tentativas e backoff exponencial com jitter, circuit breaker abrindo a 50% de falha em 30 segundos e meia-abertura em 15, cache read-through com TTL de 5 a 15 minutos em dado confidencial e até 24 horas em dado público. Toda rota nasce embrulhando o legado e sobe de estado por checklist auditado no Domain Route Registry, no padrão strangler fig, até paridade comprovada e descomissionamento.
O padrão deixa de ser treinamento e vira gate: quebra de compatibilidade de contrato bloqueia o build, promoção de estado de rota tem gate próprio e o pull request só passa com rota registrada, escopo e classe de dado conferidos contra o catálogo, replay de idempotência testado, compensação testada, correlação ponta a ponta e métricas RED por operação. Rastreabilidade sem evento exige que o correlationId nasça na borda e atravesse inclusive a chamada ao legado, com traces em OpenTelemetry. O preço declarado é rigidez deliberada: quem precisar de assíncrono não improvisa uma fila no PR — leva à arquitetura, porque introduzir tópico é violação de princípio, não detalhe de implementação.
Arquitetura de uma plataforma de orquestração de vendas que cobre a jornada do lead até a proposta assinada numa rede de concessionárias: recepção e normalização do lead, qualificação assistida por IA, sincronização com o CRM da concessionária, consulta de estoque no sistema de gestão do revendedor, visão unificada do cliente, simulação financeira, geração e versionamento de proposta com assinatura digital, devolução de status ao CRM de origem e, ao final, próxima melhor ação sugerida ao vendedor a partir da camada analítica. A plataforma se organiza em seis camadas — cliente em navegador e tablet, camada de borda com autenticação, autorização por papel, resolução de inquilino, agregação e limitação de taxa, serviços de domínio para lead, cliente, estoque, proposta, financiamento, pagamentos e trabalhos assíncronos, um hub de integração, uma camada de dados em arquitetura de medalhão até a camada de serviço, e a camada de IA — com o frontend nunca tocando o backend diretamente. Onze componentes têm responsabilidade, entradas, saídas e dependências mapeadas uma a uma, e treze sistemas externos entram no mapa com fase, conector e status declarados.
O dado comercial não vive na montadora: vive fragmentado nos sistemas de cada concessionária, um por revendedor, sem padronização — plataformas distintas de gestão de revenda concentrando lead, cadastro de cliente, histórico comercial, agenda e estoque, cada uma com sua própria API. A versão anterior da arquitetura assumia um único CRM corporativo como sistema de integração; a confirmação de que o piloto rodaria sobre dois CRMs de concessionária distintos, mais um sistema de gestão de estoque de terceiro, invalidou essa premissa antes da primeira linha de código.
Estender o padrão de adaptador, já decidido para os sistemas de estoque, também ao conector de CRM: duas interfaces comuns, uma por família de sistema, com um adaptador por fornecedor implementando os mesmos métodos de sincronizar, buscar, criar no sistema externo e obter histórico. A seleção acontece em tempo de execução por um campo de provedor registrado no cadastro da concessionária, resolvido por fábrica — o serviço de domínio nunca sabe qual sistema externo está ativo. A tradução é unidirecional por regra: o adaptador traduz o modelo canônico para a API externa, nunca o inverso; erro de quatro centos, cinco centos ou tempo esgotado é capturado no adaptador, normalizado para uma exceção de integração canônica e repassado ao disjuntor; e o adaptador não contém nenhuma regra de negócio de domínio, é exclusivamente camada de tradução de protocolo. O modelo canônico carrega identificador externo, inquilino, provedor e correlação como chaves obrigatórias, e a matriz de direção de dados declara, por domínio, quem é o sistema mestre, o que entra, o que sai, se há devolução de status e qual a restrição de dado pessoal.
Trocar o CRM de uma concessionária deixa de impactar o serviço de domínio ou a camada de borda, e um sistema novo entra como arquivo de adaptador novo, sem reescrita de lógica de negócio. O custo declarado é que a interface precisa estar definida antes do primeiro sprint de construção — é bloqueante para o desenvolvimento dos adaptadores, e por isso virou condição de entrada de fase, não item de backlog. A alternativa rejeitada foi explícita: conector direto para o CRM do primeiro piloto com refatoração posterior, descartada porque o custo de reescrita supera o de abstrair desde o discovery. Ficou registrado, junto com a decisão, o que ainda não estava decidido — provedor de nuvem em avaliação, versionamento de API, disjuntor por biblioteca de aplicação em vez de malha de serviço, funcionamento offline do tablet por cache local, assinatura digital condicionada a jurídico, propriedade da plataforma de dados e o papel do CRM corporativo. Declarar a pendência com prazo e responsável, em vez de assumir premissa, é o que impede que a decisão de arquitetura seja tomada por omissão no meio da construção.
Análise de lacunas e desenho do estado alvo de um hub de integração de abastecimento embarcado no aplicativo de bancos parceiros, para estendê-lo do combustível líquido à recarga de veículo elétrico. O hub existente é uma camada de orquestração posicionada acima do processador de autorização proprietário: a etiqueta de rádio no para-brisa se comunica com o terminal do posto por protocolo próprio, o terminal pede autorização ao processador, e só depois de liquidada a transação o hub recebe o evento e o distribui para o motor de preço em tempo real, o motor de benefícios e a API do parceiro. Cinco características desse desenho impedem uma sessão de carga elétrica: o hub é sem estado e pós-fato, há um único protocolo de captura, há um único tipo de abastecimento, a notificação ao parceiro é um gancho único de fim de transação sem ciclo de vida, e a liquidação é síncrona e de valor fechado. O trabalho identificou sete capacidades novas e três adaptações, e desenhou a sessão como máquina de estados explícita — identificada, confirmada, pré-autorizada, carregando, encerrando, capturada, conciliada — com ramos de suspensão, recusa e disputa.
A sessão elétrica é longa, multiprotocolo e de valor desconhecido no início — o oposto exato do modelo de autorização única e valor fechado do combustível. O carregador fala um protocolo aberto sobre conexão persistente, com início remoto, leituras de medidor ao longo do tempo e encerramento; alcançar rede de terceiros exige assumir o papel de provedor de mobilidade elétrica sob outro protocolo padronizado, com módulos de token, localização, sessão, registro de detalhe de carga e tarifa. Nada disso cabe num gancho de fim de transação. E a identificação por placa, que é o diferencial de baixo atrito do produto, tem um problema que nenhuma arquitetura resolve sozinha: placa é dado público e clonável.
Seis decisões registradas. A placa identifica mas não autoriza: a sessão exige confirmação explícita do motorista no aplicativo do banco como segundo fator, com alternativa de rádio ou código no próprio carregador, e antifraude mínimo cruzando placa lida, geolocalização do carregador e janela temporal da sessão. A cobertura entra primeiro por roaming como provedor de mobilidade, com um piloto fino de gestão própria de carregadores mantido em paralelo para que a competência interna não atrofie e a dependência de terceiro não vire refém. O pagamento troca autorização única por reserva de valor máximo e captura do valor real medido, com captura parcial, expiração de reserva e cobrança separada de ociosidade — construído sobre o mecanismo de autorização pré-aprovada e régua de cobrança que já existia e já estava homologado, em vez de um trilho novo. A coordenação é saga com estado no hub, escolhida sobre coreografia por auditabilidade, com fila de mensagens mortas para falha de captura e divergência de registro de carga. Um roteador de abastecimento agnóstico com adaptadores plugáveis entra já como abstração, com apenas o adaptador elétrico ativo, para que o combustível volte depois atrás do mesmo contrato. E a jornada vive numa aplicação web embarcada servida por uma camada de borda do parceiro, reusando o canal de mensagens que o aplicativo já implementa, com uma ponte nativa fina isolando o que autoriza valor: credencial, número de cartão e chave nunca transitam na camada embarcada.
A superfície de fraude cai drasticamente ao custo de um toque na jornada, e cria dependência de notificação em tempo real entre banco e hub — mantendo aberto o caminho para identificação autônoma por placa numa fase posterior, condicionada a pontuação de risco madura. O roaming entrega cobertura rápida com custo de equipamento diferido, em troca de menos controle de experiência e de granularidade de dado, e de depender da conciliação de registro de carga do operador. A reserva de valor alinha o trilho financeiro à natureza da sessão e reaproveita mecanismo homologado, reduzindo risco de certificação, mas introduz gestão de reservas órfãs — sessão abandonada ou conexão caída — que exige expiração e tempo limite em cada transição de estado. A saga dá ponto único de verdade e auditoria ao preço de o hub assumir complexidade de orquestração e idempotência. E a jornada embarcada faz um único código servir qualquer banco e permite iterar experiência sem novo lançamento de aplicativo, em troca de a homologação de segurança de cada banco entrar no caminho crítico do cronograma. Os quatro riscos vigiados foram nomeados junto com sua mitigação: clonagem de placa, divergência entre leitura de medidor, registro do operador e captura financeira, reservas órfãs, e indisponibilidade do operador no roaming.
Apoio de arquitetura e produção do desenho técnico de solução, pela vertical de consultoria digital de uma bandeira global de pagamentos, para habilitar a experiência de milhas dentro do aplicativo de um banco de varejo. O estado inicial era assimétrico: saldo e movimentos viviam numa plataforma de fidelidade de mercado que é a autoridade única do saldo, com uma conta de milhas por cliente agregando todos os cartões daquele titular; o acúmulo chegava por arquivo em lote do core de cartões, com as regras aplicadas dentro da própria plataforma de fidelidade; e o resgate existia em banco pela internet, central de atendimento e agência de viagens — mas não no aplicativo, que é justamente o vazio que o piloto endereça. A arquitetura alvo é estritamente em camadas, com o aplicativo falando com a camada de gateway responsável por segurança, política e roteamento, que encaminha a microsserviços em contêiner, que por sua vez têm a plataforma de fidelidade como sistema de registro; o core de cartões e o core contábil só participam quando há efeito transacional ou contábil, e nunca em consulta pura. A ordem de prioridade de engenharia é reutilizar antes de construir: três microsserviços já existentes cobrem consulta de saldo e movimentos, orquestração de simulação, resgate, estornos e ajustes, e resolução segura do identificador do cartão.
A pergunta que organiza a discussão inteira, e que precisa ser comunicada de forma simples ao banco, é onde se decide o uso da milha — porque o custo de acoplamento cresce conforme a decisão se aproxima do ponto físico de aceitação. Decidir no checkout implica o máximo acoplamento com a rede: terminal, caixa registradora, adquirente, switch, rede da bandeira, processador de cartões, mensageria de autorização não padrão e pagamento dividido, além de depender do comércio para qualquer mudança de comportamento. Decidir num instrumento digital reduz o atrito na aceitação mas cria um segundo livro-razão, com risco material de divergência de saldo entre ele e a plataforma de fidelidade, além de exposição contábil, tributária e regulatória. Decidir na credencial, com seleção de fonte de recursos por transação, é o caminho estrategicamente mais alinhado — mas envolve modelagem de fonte de recursos, APIs próprias e suporte do processador.
Separar o piloto do aplicativo das três hipóteses e tratá-lo como núcleo isolado, com o ponto de venda como fase futura de descoberta própria, a carteira como produto novo com descoberta posterior, e a credencial flexível como descoberta prioritária conduzida em paralelo sem acoplar ao piloto. A plataforma de fidelidade permanece a autoridade única do saldo e nenhum canal mantém cópia autoritativa. Microsserviços existentes são reaproveitados como primeira opção, construindo novo apenas mediante brecha comprovada. Nenhum desenho depende de divisão nativa entre milhas e outra fonte na mesma autorização sem confirmação formal da bandeira e do processador — quando a divisão for necessária, resolve-se por autorização parcial com pagamento dividido ou por resgate posterior à compra, que é a melhor alternativa tática justamente por não exigir mudança no ponto de aceitação. Toda operação que altera saldo é idempotente e tem caminho de compensação explícito, com máquina de estados cobrindo simulado, pendente, reservado, confirmado, parcialmente aprovado, estornado, compensado, falho, expirado, disputado e conciliado. E nenhuma conversão de milha em valor monetário entra em produção antes de validação formal das áreas contábil, tributária e regulatória do banco.
O piloto entrega valor cedo — milhas visíveis e, conforme o alcance definido, simulação e resgate no aplicativo — sem ficar refém de decisões de rede, produto e regulação que levarão mais tempo. Manter a autoridade única de saldo elimina divergência por canal e concentra a regra de acumulação onde ela já está, ao custo de toda leitura e escrita depender da disponibilidade e da latência dessa plataforma. Exigir idempotência e compensação evita duplo débito e consumo de milha sem compra, mas obriga chave de idempotência, máquina de estados e matriz de estornos definidas desde o contrato, não depois. E condicionar a conversão a validação formal protege o banco de exposição fiscal e regulatória ao preço de transformar a conversão num portão que depende de áreas fora de tecnologia. A fronteira de responsabilidade foi mantida assimétrica de propósito e precisa permanecer assim em toda a documentação: a consultoria apoia arquitetura e desenho técnico; o banco é dono das regras de negócio, do alcance do piloto, da taxa de conversão, da experiência, da segurança, dos ambientes e da operação. Nenhuma decisão de negócio, conversão ou regulação foi assumida pela consultoria sem validação formal das áreas internas — e as pendências que restaram foram registradas como pendências, com premissa conservadora e nenhuma delas tratada como decisão tomada.
Atuação como arquiteto de soluções alocado por consultoria de TI brasileira numa operação multinacional de benefícios corporativos e meios de pagamento de frota, respondendo pelo time técnico de desenvolvimento e pelos fornecedores externos. O escopo cobria os produtos de frete e pedágio e os cartões de vale-refeição e alimentação, com liderança técnica do desenho e da construção do aplicativo de gestão de frota em iOS e Xamarin, front em Angular e back em Node.js, sobre uma base .NET em C# com MVC no front e DDD no domínio, além de serviços em WCF. A integração corporativa saiu da orquestração em BizTalk Server para Apache Camel e Apache Kafka, e as integrações com SAP e Totvs cobriam ABAP orientado a objetos, Web Dynpro, RFC e BAPI, NetWeaver e ECC, e os módulos MM e PM, incluindo integração de dispositivos móveis com o NetWeaver. A camada de exposição rodava sobre Sensedia API Management. Em paralelo, migração de API REST em Java para API REST em .NET, troca de JBoss por GlassFish nas operações de Colômbia, Brasil e México, ETL em SQL Server 2008 R2 e prova de conceito com Apache Cassandra, Hadoop, Spark e HBase para cenários de alto volume.
Operação de meios de pagamento sob dupla obrigação regulatória: certificação PCI para o processamento de cartão e ISO 27001 junto à agência reguladora de transporte terrestre para os produtos de frete e pedágio. Ao mesmo tempo, a integração corporativa dependia de um barramento proprietário caro em licença e lento em latência, e o parque estava espalhado entre servidores de aplicação e stacks diferentes por país.
Substituir a orquestração proprietária por Apache Camel e Apache Kafka em vez de renovar a licença, mantendo a conformidade como restrição de projeto e não como auditoria posterior: obter a certificação PCI para os cartões das duas bandeiras internacionais e sustentar a recertificação da ISO 27001 junto ao regulador enquanto a plataforma mudava de barramento. Padronizar a exposição sob um API Management único e convergir os servidores de aplicação entre as operações de país.
Custo e latência de integração caíram com a saída do barramento proprietário, e a conformidade sobreviveu à troca — resultado auditado por equipe internacional formada por auditores das operações da França e do México, que revisou os processos de TI de Argentina, Chile e Brasil. Em contrapartida, o desenho passou a depender de disciplina de integração distribuída onde antes havia uma ferramenta única com garantia de fornecedor, e a gestão de fornecedores externos virou parte explícita do papel de arquitetura.
Plataforma dedicada, em produção e validada em campo num resort de cerca de 450 unidades em Olímpia (SP), que une a jornada do hóspede e a operação da equipe num único sistema em tempo real. Dois aplicativos web que abrem por link ou QR, sem instalar nada: o do hóspede cobre pré-check-in com ficha digital e leitura de documentos, chave digital liberada após validação humana, traslado com GPS e radar de chegada, serviços no quarto, reservas, NPS, SOS e avisos por WhatsApp; o da equipe assume um perfil por função — portaria com leitura de placa no próprio aparelho, recepção, supervisão, central de alertas com SLA, manutenção, governança, segurança com chave-mestre auditada e gerência com painel de KPIs e relatório de plantão assistido por IA. Por baixo, um backend orientado a eventos com um serviço por domínio, visão computacional no edge para ocupação e mapa de calor sem reconhecimento facial, e clima com alerta antecipado de tempo severo.
A jornada do hóspede e a operação de um resort de grande porte vivem espalhadas em papel, planilhas, grupos de WhatsApp e sistemas que não conversam. A informação se perde no caminho, a equipe faz trabalho manual para compensar e o hóspede espera. Trocar o PMS não era opção: o risco de implantação seria maior que o problema.
Um sistema em que cada ação do hóspede vira, na hora, uma fila, um radar ou um alerta para a equipe, e o retorno volta ao hóspede em segundos. Backend hexagonal orientado a eventos com um serviço por domínio — identidade, estadia, traslado, portaria, atendimento, reservas, ocupação, alertas, projeções e notificação —, um banco por serviço, idempotência e trilha de auditoria imutável; contratos versionados antes do código; PWAs offline-first no lugar de apps de loja; inferência de vídeo no edge, sem rosto e sem imagem armazenada, com placa expurgada em 24 horas; validação humana em toda ação crítica. Multi-tenant desde o primeiro dia, com dados e marca isolados por unidade.
A plataforma roda ao lado do PMS, então a implantação é de baixo risco e a adoção é imediata — não há app para instalar nem sistema para migrar. O piloto está no ar e em uso real, dos dois aplicativos à portaria com leitura de placa, manutenção, segurança, governança, reservas, alertas, inteligência de vídeo e WhatsApp: operação, não protótipo. Em troca, cada cliente é uma instância dedicada que precisa de provisionamento, treinamento e evolução contínua — o compromisso é com quem usa, não com um lançamento.
Desenho de solução ponta a ponta para núcleo bancário, pagamentos, crédito, cobrança e seguros: capacidades de negócio mapeadas em domínios, jornadas críticas modeladas, integração com o ecossistema regulado e blueprint C4 que sobrevive à auditoria e ao comitê.
Saída do monólito sem parar o negócio: strangler fig com fronteiras negociadas, anti-corruption layer sobre o núcleo antigo, decomposição por bounded context, contratos versionados e estratégia de dados para conviver com a fonte de verdade durante a transição.
Fundação AWS pensada para carga transacional regulada: landing zone e segregação de contas, malha de rede e postura de segurança, resiliência multi-AZ com objetivo de recuperação declarado, observabilidade acionável e disciplina de custo tratada como requisito de arquitetura, não como relatório mensal.
Data lake e arquitetura de streaming para domínios de alto volume, com linhagem, qualidade e governança tratadas desde o desenho — e a aplicação de agentes de IA onde ela realmente compõe: decomposição de domínio, geração de serviço sob padrão e verificação contínua de conformidade arquitetural.
Leitura do estado atual, mapa de domínios e acoplamentos, riscos estruturais ordenados por custo de permanência e um roadmap de modernização com sequência defensável. Entrego o que está de pé, o que vai quebrar e em que ordem mexer.
Atuação dentro do programa: desenho da solução, condução técnica dos times, negociação de fronteira entre squads e áreas, revisão de design, ADRs e a responsabilidade de manter a coerência do conjunto enquanto o escopo se move.
Implantação da abordagem agêntica no seu contexto: padrão arquitetural codificado, geradores parametrizados para a sua stack, verificação de conformidade no pipeline e transferência de propriedade para o time interno — com a plataforma rodando, não em slides.
Trabalhei majoritariamente em ambientes onde indisponibilidade tem nome, valor e prazo regulatório. Os projetos variam, o denominador comum não: volume transacional alto, integração com sistemas que ninguém pode desligar e um regulador do outro lado da mesa.
DDD · C4 Model · BIAN · ADR · Event Storming · Clean Architecture · Vertical Slice · Hexagonal · CQRS · Saga · Outbox
AWS · EKS · ECS · Lambda · API Gateway · EventBridge · SQS · SNS · Aurora · DynamoDB · S3 · Terraform
Kubernetes · Docker · Kafka · RabbitMQ · Redis · PostgreSQL · OpenTelemetry · Prometheus · Grafana · GitOps
.NET · Java · Spring · Node · TypeScript · Python · OpenAPI · gRPC · contract testing · fitness functions · agentic codegen
Descreva o contexto em três parágrafos — o sistema, a restrição e o prazo. Respondo com uma leitura inicial e o formato de trabalho que faz sentido, sem proposta genérica. E-mail ou WhatsApp — Brasil ou Chile, o que for mais direto para você.
contato@jtroncoso.dev