Fundamentos e modernização
.NET, integrações, automação e evolução de legado. Nesse período, uma biblioteca de acesso a dados reduziu em 90% o esforço de criação e manutenção dessas camadas.
Arquiteto de Software · Sistemas Corporativos · Liderança Técnica
Transformo complexidade técnica em sistemas que os times conseguem evoluir.
Com mais de duas décadas em engenharia de software, atuo na interseção entre negócio, arquitetura e entrega — desenhando sistemas distribuídos, integrações e soluções cloud que precisam continuar confiáveis, compreensíveis e sustentáveis no mundo real.
30%menos tempo de resposta em fluxo crítico .NET/HANA
40%menos tempo médio de detecção e resposta
≈ 1/3do tempo para integrar um novo microserviço
Financeiro · Seguros · Tecnologia · .NET · GCP · AWS
Trajetória
O repertório arquitetural foi construído em camadas, acompanhando o aumento de responsabilidade e complexidade.
Plataformas corporativas
ERP, BI, segurança e integrações no ecossistema Microsoft, incluindo uma plataforma que centralizou o gerenciamento de mais de 23 mil contas de e-mail.
Segurança e ambientes críticos
OAuth, modernização .NET, sustentação, disponibilidade, automação e monitoramento operacional.
Sistemas distribuídos e cloud
Microserviços, Kafka, AWS, observabilidade, CI/CD, performance, resiliência e testes automatizados.
Arquitetura e governança
.NET na GCP, integrações assíncronas, grandes volumes de dados, Kubernetes, Terraform, ADRs e atuação em Centro de Excelência de Arquitetura.
Resultados e decisões em sistemas reais
Princípios importam. O que muda a conversa é mostrar onde eles produziram resultado.
Estes exemplos vêm da minha trajetória profissional e preservam o contexto dos clientes. O foco está no problema, na decisão de engenharia e no efeito observado.
Performance01
Gargalo em sistema crítico .NET sem reescrever o núcleo
Contexto. Uma aplicação corporativa em .NET Core concentrava lentidão em um fluxo de negócio crítico. A investigação mostrou que o custo estava nas consultas ao SAP HANA no caminho síncrono, e não no desenho geral do serviço.
Decisão. Fiz causa-raiz no caminho da requisição, isolei as consultas caras e otimizei a interação com o banco — sem adicionar cache genérico, réplica emergencial ou reescrever a aplicação. A intervenção ficou exatamente onde o custo era real.
Leitura arquitetural. Distribuir um gargalo de acesso a dados apenas multiplica o problema. A decisão proporcional foi reduzir o trabalho no núcleo síncrono e preservar o restante do sistema; a stack entrou como restrição, não como justificativa para introduzir um padrão novo.
Resultado30% menos tempo de resposta no sistema crítico, sem depender de mais infraestrutura.
Modernização02
APIs legadas que encareciam cada microserviço novo
Contexto. O backend legado expunha fronteiras largas e responsabilidades misturadas. Cada novo serviço puxava dependências demais, alongava a integração e aumentava o risco de regressão no que já estava em produção.
Decisão. Redesenhei as APIs por responsabilidade e contrato, separando regras de negócio, acesso a dados e borda HTTP o suficiente para que novos serviços se conectassem a contratos mais estáveis. Clean Architecture foi um meio, não o objetivo.
Leitura arquitetural. Modernização que depende de reescrita total raramente cabe em prazo real. A aposta foi tornar as fronteiras explícitas, reduzir acoplamento e permitir evolução incremental sem renegociar todo o legado a cada entrega.
ResultadoNovas integrações em cerca de um terço do tempo previsto antes do redesenho.
Observabilidade03
Detecção tardia em aplicações críticas
Contexto. Detectar e responder a falhas levava mais tempo do que o ambiente tolerava. Havia sinais disponíveis, mas pouco caminho entre “algo quebrou”, “onde está o problema” e “qual ação tomar”.
Decisão. Estruturei monitoramento na AWS pensando no fluxo do incidente, complementado por automações em Python para ampliar sinal, reduzir passos manuais e encurtar o intervalo entre sintoma, diagnóstico e ação.
Leitura arquitetural. Observabilidade que não melhora a decisão operacional vira coleção de gráficos. Ferramenta, script ou alerta só têm valor quando reduzem o tempo até a ação e deixam o caminho de diagnóstico mais claro.
Resultado40% menos tempo médio para detectar e responder a incidentes.
Arquitetura atual04
Movimentar dados de crédito sem tratar tudo com a mesma consistência
Contexto. Em uma plataforma de serviços financeiros no domínio de crédito e empréstimos, APIs, processamento assíncrono, cargas agendadas e grandes volumes precisam coexistir entre BigQuery, Redis, serviços .NET e banco relacional.
Decisão. Trabalho a direção técnica separando o que precisa ser síncrono, o que pode ser evento, o que pertence a cargas agendadas, o que exige estado de baixa latência e o que permanece no relacional. As decisões são explicitadas em fluxos, ADRs, requisitos não funcionais e revisões de solução antes de virarem implementação consolidada.
Leitura arquitetural. Em domínio financeiro, o erro caro é tratar todo dado com o mesmo modelo de consistência. GCP, GKE, Pub/Sub, Apigee e Terraform são o chão de fábrica; o julgamento arquitetural está em ownership, atraso aceitável, custo e capacidade de evolução.
ResultadoDecisões de integração e movimento de dados tornadas explícitas e acompanhadas junto aos times de engenharia e ao Centro de Excelência de Arquitetura.
Os resultados quantitativos acima são de 2020–2021, em aplicações críticas .NET/AWS. Desde 2025, minha atuação está concentrada em arquitetura de software, crédito, GCP e governança técnica.
Como penso arquitetura
Arquitetura é um sistema contínuo de decisões.
O valor não está no diagrama em si. Está em tornar decisões explícitas, testar hipóteses cedo, compreender restrições e criar ciclos de feedback que mantenham o sistema evolutivo.
Problema e atributos de qualidade antes da tecnologia
Disponibilidade, consistência, desempenho, segurança, custo, operabilidade e evolução definem as forças do sistema. Padrões e produtos entram depois, como resposta a essas forças.
Fronteiras preservam ownership
Evito atalhos que atravessam diretamente dados ou regras de outro domínio. Prefiro contratos explícitos, adapters e responsabilidades claras, mesmo quando isso introduz algum custo adicional de integração.
Consistência distribuída exige desenho de recuperação
Retries, idempotência, resultados desconhecidos, compensação, DLQ e reprocessamento fazem parte da solução. O happy path sozinho não descreve um sistema distribuído operável.
Observabilidade precisa atravessar fronteiras
Uma operação deve continuar diagnosticável ao cruzar HTTP, persistência, processamento assíncrono e mensageria. Correlação, tracing e contexto operacional são responsabilidades diferentes e complementares.
Concorrência deve ser controlada no menor escopo útil
Prefiro serializar a chave ou recurso realmente disputado em vez de reduzir o throughput global. A estratégia precisa considerar consistência, contenção, provider de dados e comportamento real sob concorrência.
Decisões arquiteturais têm contexto e prazo de validade
Registro alternativas, consequências e riscos porque uma decisão correta hoje pode deixar de ser adequada amanhã. Governança útil preserva o porquê e facilita evolução, em vez de congelar o desenho.
Open source como evidência de engenharia
Construo ferramentas que codificam os princípios de engenharia que defendo.
Open source não é o centro da minha identidade profissional. É onde torno parte do meu raciocínio de engenharia observável: contratos de domínio explícitos, acesso a dados mais seguro, feedback automatizado de qualidade e governança arquitetural.
Evidência pública complementar
Parte do meu raciocínio arquitetural pode ser inspecionada em código.
O projeto POC Arquitetura materializa decisões que também fazem parte do meu repertório profissional: bounded contexts, Kafka, Outbox/Inbox, idempotência, sagas, Keycloak, OpenTelemetry, ADRs, runbooks e readiness para produção. Ele não substitui a trajetória profissional; torna uma parte desse raciocínio observável.
Modelagem de Domínio01
Brazilian Primitives for .NET
Value objects fortemente tipados para identificadores brasileiros, preservando semântica de domínio e mantendo preocupações de persistência opcionais e explícitas.
Ver repositório ↗Contratos de Dados02
Dapper.TypedParameters
Pacotes específicos por provider que tornam explícitos os contratos de parâmetros de banco para SQL Server e PostgreSQL em vez de depender apenas de inferência.
Ver repositório ↗Governança Arquitetural03
DotNetRepoInspector
Uma visão determinística de repositórios .NET baseada em metadados avaliados pelo MSBuild para CI/CD, automação, governança e evidências de engenharia.
Ver repositório ↗Qualidade Automatizada04
ComplexityAnalysis.Analyzers
Analyzers Roslyn que transformam complexidade estrutural e algorítmica em feedback repetível dentro do fluxo de desenvolvimento.
Ver repositório ↗Toolkit de arquitetura
Referências públicas que uso para tornar conversas de arquitetura mais concretas.
DDD, fronteiras de contexto e registros de decisão são mais úteis quando ajudam os times a raciocinar juntos — não quando viram cerimônia.
Artigos e compartilhamento
Escrevo para tornar ideias complexas de engenharia mais aplicáveis.
Meus textos conectam teoria de arquitetura à realidade de implementação — principalmente Domain-Driven Design, sistemas distribuídos, backend, qualidade de software e os trade-offs por trás das decisões técnicas.
Leia meus artigos no Medium ↗Entities e Value Objects: identidade, igualdade e comportamento no modelo de domínio
Ler artigo ↗Arquitetura de Segurança e Arquitetura de Software
Ler artigo ↗Monólito modular em .NET
Ler artigo ↗Sobre
De escrever código a moldar os sistemas ao redor dele.
Sou Rodrigo de Oliveira, Arquiteto de Software com mais de 20 anos de experiência. Minha trajetória passa por ambientes críticos nos setores financeiro, segurador e de tecnologia, com atuação em empresas como CI&T, IBM e Pearson — da implementação e modernização de sistemas à direção arquitetural e governança técnica.
Sou formado em Análise de Sistemas e licenciado em Filosofia. Essa combinação reforça uma característica central do meu trabalho: entender restrições, questionar pressupostos, explicitar trade-offs e manter decisões arquiteturais próximas o suficiente da engenharia para serem testadas na prática.
Arquitetura de Software
Sistemas Distribuídos
.NET / C#
GCP / AWS
Kafka / Pub/Sub
Terraform / Kubernetes
DDD
Observabilidade
APIs e Integrações
Governança Técnica
Presença profissional
O LinkedIn é o melhor lugar para acompanhar minha trajetória profissional atual.
O GitHub mostra como construo. O Medium mostra como penso. O LinkedIn reúne a história profissional mais ampla.