Foundations and modernization
.NET, integrations, automation and legacy-system evolution. During this period, a data-access library reduced the effort to create and maintain those layers by 90%.
Software Architect · Enterprise Systems · Engineering Leadership
I turn technical complexity into systems teams can evolve.
With more than two decades in software engineering, I work at the intersection of business, architecture and delivery — shaping distributed systems, integrations and cloud solutions that need to remain reliable, understandable and maintainable in the real world.
30%lower response time in a critical .NET/HANA flow
40%lower average incident detection and response time
≈ 1/3of the time to integrate a new microservice
Financial services · Insurance · Technology · .NET · GCP · AWS
Trajectory
My architecture repertoire was built in layers as responsibility and system complexity increased.
Enterprise platforms
ERP, BI, security and integrations in the Microsoft ecosystem, including a platform that centralized the management of more than 23,000 email accounts.
Security and critical environments
OAuth, .NET modernization, support, availability, automation and operational monitoring.
Distributed systems and cloud
Microservices, Kafka, AWS, observability, CI/CD, performance, resilience and automated testing.
Architecture and governance
.NET on GCP, asynchronous integrations, large data volumes, Kubernetes, Terraform, ADRs and Architecture Center of Excellence work.
Results and decisions in real systems
Principles matter. Evidence shows whether the decisions actually worked.
These examples come from my professional experience while preserving client context. The focus is the problem, the engineering decision and the observed outcome.
Performance01
Bottleneck in a critical .NET system without rewriting the core
Context. A corporate .NET Core application concentrated latency in a critical business flow. Investigation showed that the cost was in SAP HANA queries on the synchronous path, not in the overall service design.
Decision. I performed root-cause analysis along the request path, isolated expensive queries and optimized the database interaction — without adding generic caching, an emergency replica or rewriting the application. The intervention stayed exactly where the cost was real.
Architecture lens. Distributing a data-access bottleneck simply multiplies the problem. The proportional decision was to reduce work in the synchronous core and preserve the rest of the system; the stack was a constraint, not an excuse to introduce a new pattern.
Outcome30% lower response time in the critical system, without depending on additional infrastructure.
Modernization02
Legacy APIs that made every new microservice more expensive
Context. The legacy backend exposed broad boundaries and mixed responsibilities. Each new service pulled in too many dependencies, lengthened integration and increased regression risk in what was already running in production.
Decision. I redesigned APIs around responsibility and contract, separating business rules, data access and the HTTP edge enough for new services to connect through more stable contracts. Clean Architecture was a means, not the objective.
Architecture lens. Modernization that depends on a full rewrite rarely fits real delivery constraints. The bet was explicit boundaries, lower coupling and incremental evolution without renegotiating the entire legacy system for every delivery.
OutcomeNew integrations in about one third of the time estimated before the redesign.
Observability03
Late failure detection in critical applications
Context. Detecting and responding to failures took longer than the environment tolerated. Signals existed, but the path from “something broke” to “where is the problem” and “what action should we take” was weak.
Decision. I structured AWS monitoring around the incident flow and complemented it with Python automation to improve signal, reduce manual steps and shorten the interval from symptom to diagnosis to action.
Architecture lens. Observability that does not improve operational decisions becomes a collection of dashboards. A tool, script or alert only matters when it reduces time to action and makes the diagnostic path clearer.
Outcome40% lower average time to detect and respond to incidents.
Current architecture04
Moving credit data without treating every flow with the same consistency model
Context. In a financial-services platform in the credit and lending domain, APIs, asynchronous processing, scheduled workloads and large volumes must coexist across BigQuery, Redis, .NET services and relational databases.
Decision. I work on technical direction by separating what must remain synchronous, what can become an event, what belongs to scheduled workloads, what requires low-latency state and what remains relational. Decisions are made explicit through flows, ADRs, non-functional requirements and solution reviews before implementation becomes a fait accompli.
Architecture lens. In financial domains, the expensive mistake is treating every piece of data with the same consistency model. GCP, GKE, Pub/Sub, Apigee and Terraform are the factory floor; architectural judgment is in ownership, acceptable delay, cost and evolvability.
OutcomeIntegration and data-movement decisions made explicit and followed through with engineering teams and the Architecture Center of Excellence.
The quantitative outcomes above are from 2020–2021 in critical .NET/AWS applications. Since 2025, my work has focused on software architecture, credit, GCP and engineering governance.
How I think about architecture
Architecture is a continuous decision system.
The value is not in the diagram itself. It is in making decisions explicit, testing assumptions early, understanding constraints and creating feedback loops that keep the system evolvable.
Problem and quality attributes before technology
Availability, consistency, performance, security, cost, operability and evolution define the system forces. Patterns and products come later, as responses to those forces.
Boundaries preserve ownership
I avoid shortcuts that reach directly into another domain's data or rules. I prefer explicit contracts, adapters and clear responsibilities, even when that introduces some additional integration cost.
Distributed consistency requires recovery design
Retries, idempotency, unknown outcomes, compensation, dead-letter handling and reprocessing are part of the solution. The happy path alone does not describe an operable distributed system.
Observability must cross boundaries
An operation should remain diagnosable as it crosses HTTP, persistence, asynchronous processing and messaging. Correlation, tracing and operational context are different but complementary responsibilities.
Concurrency should be controlled at the smallest useful scope
I prefer serializing the actual contested key or resource instead of reducing global throughput. The strategy must consider consistency, contention, data provider and real concurrent behavior.
Architecture decisions have context and an expiration date
I record alternatives, consequences and risks because a decision that is right today may stop being adequate tomorrow. Useful governance preserves the why and enables evolution instead of freezing the design.
Open source as engineering evidence
I build tools that encode the engineering principles I advocate.
Open source is not the center of my professional identity. It is where I make part of my engineering thinking observable: explicit domain contracts, safer data access, automated quality feedback and architecture governance.
Complementary public evidence
Part of my architecture reasoning can be inspected in code.
POC Arquitetura materializes decisions that are also part of my professional repertoire: bounded contexts, Kafka, Outbox/Inbox, idempotency, sagas, Keycloak, OpenTelemetry, ADRs, runbooks and production readiness. It does not replace professional experience; it makes part of that reasoning observable.
Domain Modeling01
Brazilian Primitives for .NET
Strongly typed value objects for Brazilian identifiers, designed to preserve domain semantics while keeping persistence concerns optional and explicit.
View repository ↗Data Contracts02
Dapper.TypedParameters
Provider-specific packages that make database parameter contracts explicit for SQL Server and PostgreSQL instead of relying only on inference.
View repository ↗Architecture Governance03
DotNetRepoInspector
A deterministic view of .NET repositories based on evaluated MSBuild metadata for CI/CD, automation, governance and engineering evidence.
View repository ↗Automated Quality04
ComplexityAnalysis.Analyzers
Roslyn analyzers that turn structural and algorithmic complexity into repeatable feedback inside the development workflow.
View repository ↗Architecture toolkit
Public references I use to make architecture conversations more concrete.
DDD, context boundaries and decision records are most useful when they help teams reason together — not when they become ceremony.
Writing & knowledge sharing
I write to make complex engineering ideas easier to apply.
My articles connect architecture theory with implementation reality — especially Domain-Driven Design, distributed systems, backend engineering, software quality and the trade-offs behind technical decisions.
Read my articles on Medium ↗Entities e Value Objects: identidade, igualdade e comportamento no modelo de domínio
Read article ↗Arquitetura de Segurança e Arquitetura de Software
Read article ↗Monólito modular em .NET
Read article ↗About
From writing code to shaping the systems around it.
I am Rodrigo de Oliveira, a Software Architect with more than 20 years of experience. My career spans critical environments in financial services, insurance and technology, including roles at CI&T, IBM and Pearson — from implementation and modernization to architecture direction and engineering governance.
I hold degrees in Systems Analysis and Philosophy. That combination reinforces a core part of how I work: understanding constraints, questioning assumptions, making trade-offs explicit and keeping architectural decisions close enough to engineering to be tested in practice.
Software Architecture
Distributed Systems
.NET / C#
GCP / AWS
Kafka / Pub/Sub
Terraform / Kubernetes
DDD
Observability
APIs & Integrations
Engineering Governance
Professional presence
LinkedIn is the best place for my current professional trajectory.
GitHub shows how I build. Medium shows how I think. LinkedIn brings the broader professional story together.